Complex inheritance tree
(also known as the "Terrible inheritance tree of doom", "Drunk Deriving" or "Idiotree")
If you have a inheritance tree of more than three levels deep, you have a problem. First of all, you should be careful with any inheritance, because it couples class tighter than need be:
Inheritance breaks encapsulation. Support for inheritance implies that (some) implementation details have to be published!
publiclook on Abstract Classes:
The WORST examples of inheritance are things like subclassing Button every time a Button that communicates with another object is needed. Many (all) of the famous C++ design patterns exist to reduce coupling between objects. Events, the Command pattern, and The Chain of Responsibility pattern exist in part to avoid having to subclass Button ;) C++ templates also exist to avoid subclassing every time a new type needs to be used. Isn't it interesting how many idioms, patterns, and language constructs exist to avoid subclassing ?
Furthermore, there is a perfectly good alternative, especially if you are developing an abstract class:
In general, object composition should be favored over inheritance. It promotes smaller, more focused classes and smaller inheritance hierarchies. Most designers overuse inheritance, resulting in large inheritance hierarchies that can become hard to deal with. A design based on object composition will have less classes, but more objects. The behavior of such a system depends more on the interrelationships between objects rather then being defined in a particular class.
If you have multiple classes supporting the same protocol or group of methods, would you not define a shared interface? If you have a shared interface, do you still need to use inheritance to share implementation? Could you not share implementations by containment?
Instead of coupling classes tightly by letting them extending each other, you should couple them loosely by letting them use each other interfaces. If you do this, there is little room left for many abstract classes.