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.