A class hierarchy, also called a class taxonomy, is a group of related classes that are connected through inheritance to do similar things. The top of the hierarchy can be a single base class from which all other classes below it are derived, or the hierarchy can have multiple base classes whose functionalities merge together later in one or more derived classes. The relationships between the classes can be illustrated as trees, and each smaller tree within the large taxonomy can also be considered a hierarchy.
Not all class hierarchies can have multiple roots, and the structure of any class hierarchy depends largely on the language it's written in. C++ allows multiple inheritance, so complex hierarchies can be built with multiple roots and multiple trees that merge into one another. Java®, on the other hand, is limited to single inheritance, so its class relationships are usually simpler, built as relatively self-contained trees with a single root. Interface inheritance can add some complexity to a class hierarchy in Java®, but interfaces almost never are invoked in such a complex framework that it would be like merging trees together.
The components of a class hierarchy can vary in type and function, as long as the rules of the language are always followed with respect to inheritance. Classes in a hierarchy can be public, protected, abstract, concrete, or virtual. Interfaces, global functions, and friends may also be used. Depending on the computer language, some of these types may lend themselves better to inheritance than others. In general, hierarchies are very flexible, and can be used in many ways for many purposes.
There are no hard rules concerning where particular types of classes must be placed in a hierarchy. Any class can conceivably be any of the types mentioned above. In general, the last classes in the hierarchy that have no derived classes beneath them should be public and concrete. Since purely abstract class hierarchies can also exist, however, this is just a rule of thumb.
Although a class hierarchy can be a useful tool to organize code and encapsulate functionality, there may be times in which delving too deep into a hierarchy may actually confuse the code, rather than clarify it and make it easier to maintain. Building a robust relationship between many classes takes a certain amount of foresight; while it might initially be easier to break code into many small pieces, those small pieces may become more difficult to handle later. When built properly, a class hierarchy aids both developers and users in determining how classes work. If it is built without maintenance and clarity in mind, the many levels of inheritance can be confusing to look back on and understand.