Document Updated 5/17/2002
I have been asking for 3 examples of typical "small or medium custom business applications" or portions that demonstrate OO's superiority for this niche.
I will even supply the procedural/relational version which to compare it to if you do not wish to.
It can either be real code or pseudo-code. The example provider is responsible to answer any questions about the example. The example should be well-documented, and any oddities of the particular language used should be clarified.
The 3 samples must be generally different from each other. They cannot repeat the same "pattern" between them, unless you can demonstrate that the pattern is common. "Common" will be defined as roughly 10 percent of all code. The total occurance of the patterns of all 3 examples should be at least about 25 percent of all code, unless the "savings" are significant.
They cannot be something that is easily available as a separate component or utility, such as an OCX or Crystal Reports, unless it can be shown that such components are not satisfactory.
Remember that one must think like a business manager when weighing the costs. Your personal ideals about how software should be made is not relevant here, I am sorry to say. In the real world, managers call the final shots, not the developers nor utopian authors.
It is fairly likely that there will be some disagreement about whether something fits the above niche. Although the final judgment will probably be the burden of the reader (I will post or link to any challenges meeting base requirements), hopefully enough details can be gathered about the example to know whether it is authentic or merely a textbook pattern in business clothing.
The example size should be no more than about 25K of ASCII text, unless size is needed as part of the demonstration.
One must demonstrate their example's superiority using basic metrics. I have provided some basic metrics in my Goals write-up. However, one is not limited to just these. Bertrand Meyer offers a set in chapter 3 of the well-known OOSC2 (Although I find his "open/closed" principle a little vague.)
The metrics and/or described advantages must be clearly describable in terms of saved labor, mistakes prevented, etc. A typical way to do this is to describe the thought processes and steps that a typical programmer may go through as they maintain code by adding, changing, and/or deleting items. This is sometimes known as change impact analysis. Please consider a typical variety of changes, not just changes that favor your favorite paradigm.
Unfortunately, metrics that rely on long-term statistics to demonstrate may not be appropriate here unless the study was actually carried out and easily view-able and verifiable.
Some of the most common metrics are code size (LOC), proximity (grouping related items together), protection (ex: scope, boundary, type, and template ensuring by the compiler), and factoring. However, these are not the only possible metrics. Language and paradigm simplicity is another metric that is often ignored. Simple metrics will be given priority over complex or vague metrics. Thus, one is encouraged to break complex metrics down into simpler ones if possible. For example, "encapsulation" can be viewed as a combination of proximity and protection (keeping related things together and compiler complaining when things inside a "group" are attempted to be used with parts from an outside group.)
I would suggest avoiding GUI-intensive examples, unless you have a specific point about GUI's. There are too many GUI API variations and philosophies out there. In other words, a GUI-intensive example will likely open a complex can of worms. Thus, try to dumb-down the GUI requirements to only what you feel is necessary for the demonstration. This is not an outright rejection of GUI examples, just a warning for the time-impaired.
Note that if you use a code processor or IDE to dismiss pure code weaknesses or present an advantage, then the alternative is also allowed to do the same.
Excluded are examples which show that OO has "better compile-time protection". I already have agreed that OOP can provide better compile-time checking in some (vrey limited IMO) circumstances. Note that OO languages like Smalltalk would not see these.
You are welcome object to these rules if you think they are unrealistic.
So far, nobody has met the challenge. Some have demonstrated possible OO advantages for other niches, such as embedded systems, especially related to the Driver Pattern.
Suggested application examples ideas that have popped up include:
See also:
OOSC2 Ch. 20 Panel example
Country Tax example
"Undo" Example
Media BS-Watch
Book Library Example