Over Used Oop Examples

OOP examples that TopMind claims are used way too often, but don't seem to extrapolate to realistic business modeling.

Device driver
GUI
Shapes
Stack
Animals
Employee subtypes (lack multidimensional taxonomies)
Car sub-assemblies

What do you want to see, then? Why don't they extrapolate to realistic business modeling? What is "realistic business modeling"?

Generally the problem with realistic business models is that they vary from business to business.

I would personally like to see OO designs that handle something like the CampusExample. Perhaps make it web-based so that we don't have a GUI API war on top of it all.

The problem with many OO examples (and HOF also) is that they assume too much regularity. They don't show how to account for the EightyTwentyRule where the abstraction is too perfect compared to the actual situations. The EightyTwentyRule is probably the biggest buggaboo for astractors.

[The following moved here from PrinciplesOfObjectOrientedDesign - no need to have a discussion about this on two different pages, and it fits this topic much better than the principles page. -- FalkBruegmann]

Many of these principles or the examples used tend to focus on systems software instead of business or domain modeling. Is there is systems-software bias among the OO community? They are overly heavy with device-driver and embedded device examples, for instance. Some RelationalWeenies suggest that OO is weak at business modeling because it tends to try to reinvent the database in code without learning from database history's lessons.

Which principles or examples focus on systems software?

I don't know of any that focus on business modeling. Let me restate the issue. I do not find the above material very applicable to business modeling. Although Robert Martin has a payroll example, I disagree with it on the grounds that its taxonomy of employees is artificial, uses IS-A where HAS-A is more appropriate (PolymorphismLimits). If we find more, then maybe we can create an OoBusinessModelingMethodologies? or something. As it stands, the above favors systems software.

The principles above are applicable to software development in any domain. They guide how code is organized, not what it is used for. They don't favor system software any more than they favor any other type of software.

I tend to disagree. System software tends to deal with dynamic implementations of static interfaces, while business modeling usually only has one implementation, yet has dynamic interfaces. Further, it may be a requirement to implement database-like operations (read, update, delete, list, save, sort, etc.) in system software because that is the pre-designed interface you are given as part of formal standards or de-facto standards of other vendors, but often not appropriate in business software (ReinventingTheDatabaseInApplication). IOW, the invariants and things a designer has control over are vastly different between the domains.

I've been writing business and system software for the last 17 years and I can't figure out what you're talking about. What's a "dynamic interface"?

An interface that changes a lot. For example, device driver interfaces are not going to change very often because a lot of implementors depend on them, and if you change something, a bunch of implementors have to change something also. How about you pick your favorite example above, and show how it applies to both domains.

OK, you mean dynamic APIs. My experience is that both system and business software need stable APIs that can be expanded. OO doesn't help much, since most component APIs look procedural from the outside. Relational query languages provide no way of defining component level APIs, dynamic or otherwise.

That generally seems to agree with WhenToUseWhatParadigm.