What-If Inheritance means creating a hierarchy of abstract subclasses with a single concrete class at the bottom. The abstract classes usually break the behaviour along somewhat logical - though perhaps arbitrary - lines. An example might be:
DomainObject <- Component <- ManifestComponent? <- SharableComponent? <- HardwareComponent?
Where only HardwareComponent? is concrete. When pressed about why there are all these abstract classes, the usual answer is, "Well...what if someone wants to make a NonSharableComponent????"
To me, this violates lots of common-sense (and XP) principles. DoTheSimplestThingThatCouldPossiblyWork...SolveTheProblemAtHand?...DontPredictTooFarInAdvance?.
(Not to mention YouArentGonnaNeedIt.)
PrematureGeneralization and CompilableComment? in action.
a.k.a. SpaghettiInheritance.
I can see how this would make sense if you were in an environment where refactoring was difficult, expensive, or overly time-consuming. Then adding in the hypothetical classes early might make sense. Fortunately, we're not in that sort of environment. Refactoring is cheap, quick, and (if you have sufficient unit tests built in) easy. So we do it mercilessly. <g>
While I agree that WhatIfInheritance violates lots of good principles that are currently en vogue, isn't it right in line with sort of the early object analysis and design philosophies?
And (in a half-hearted attempt at devil's advocacy) is there any strength to the argument that you wanted to put in all those abstract classes as design clues to whoever is maintaining your code in the future?
If I had an environment where refactoring was difficult, expensive, or overly time-consuming, I can think of one big refactor up front that would make the others easy. Perform the refactor "Substitute Environment". --PCP
If you were making a library to be used by others, it could make a lot of sense.
This is probably true. It is also why we call such things "PolyBloodyHardReuse".
Speaking from experience, WhatIfInheritance is one of the many symptoms of the AnalysisParalysis AntiPattern, or just procrastination in general. I still struggle with it. It's a nasty bad habit. -- RobHarwood
A related question is "Well...what if someone wants to use a NonSharableComponent????" In C++ and Java, that notion needs to be expressed in a class and that class inherited from explicitly. In Smalltalk, it's a non-issue. Hence in Smalltalk people tend not to bother with the NonSharableComponent? class unless/until there is some code that belongs there. (If then. Often the code can go in the base class ManifestComponent? and be just ignored by client code that doesn't need it.)