This may be part of why I decided that sales was not for me:   I was going to be constantly attending product-training classes, for a company that sold a tremendous variety of things.   Even in the present analogy, “cars” and “motorbikes” are not the same thing, except to the extent that both have wheels, they might be colored red, and they can go very fast.   Even though the dealer, in our example, can “introspect” (i.e. “plainly see”) both objects and determine, for example, the number of wheels that each one possesses, that Dealer is still constantly going to be attending new product-training courses.   And in so doing, constantly growing in complexity and declining in maintainability.   It may well be argued that this is where spaghetti comes from.   It truly is a very complex problem, and I do not mean to trivialize it (let alone to suggest that my wild-haired idea has any actual relevance upon it).   But I have encountered the consequences of designs (as we all have...) many times.   “The fact that both of them are, say, ‘vehicles,’ is useful only to a point.”   Our purpose is to build easily-extendable code that will last a dozen years, not to count wheels, and, that’s hard.   While these metaphors do have merit, and are generally worthy based on these merits that they have, they are not the full solution.

(And so, realizing that I have made no specific conclusion here, I shall now climb down off of this box and put it away.)

The hope is that the dealer may, without any knowledge whatsoever about those items, just put a list in front of the client to answer. The only thing he knows is how to contact the builder with that filled out list and how to get the finished product into the hands of the client.

I agree with jethro: as long as the dealer knows that there is some sort of tick-box list that he/she needs to put in front of the customer, then put in an envelope and assume that the builders knows what to do with this then it should be ok.

I was referring more to the inherent complexity ... to the potential downside of having a large amount of product/model (etc.) specific decision making scattered hither-and-yon.   I deal mostly with legacy applications, including some that were launched with the most pristine of original designs, which quickly fell into grief on this point.   There will come a time when one of two things may happen:

1. “Commonality” that naturally is sought to be implemented one-time in a parent class, becomes so inherently complex that the ancestor-class starts to devolve from a clean purebred to a mongrel pup.
2. The “descendents” start to lose commonality with one another, because they have truly become apples and oranges, or apples and bricks.

A “class hierarchy,” after all, is a dependency-tree that ties all of its participants together more-or-less at the hip.   (Or at the head, or an arm, or a foot.)   No matter how or where they are tied, they are tied.   Of course this has originally been done with the very best of intentions and with deliberate purpose.   It is relatively easy and harmless to do this when one anticipates incremental change; much harder when business reality dumps radical change into the picture and the system has no choice but to accommodate it.   The ugly word, “wedge,” and words considerably more ugly, will now enter daily conversation, and furtive hits on http://www.monster.com will increase.