A class hierarchy is a group of related classes linked through inheritance. The hierarchy can have one or multiple base classes, and its structure depends on the programming language. Classes can vary in type and function, and there are no strict rules for their placement. While a hierarchy can be useful, it can also confuse code if not built with maintenance and clarity in mind.
A class hierarchy, also called a class taxonomy, is a group of related classes that are linked through inheritance to do similar things. The top of the hierarchy can be a single base class from which all other lower classes derive, or the hierarchy can have multiple base classes whose functionality is later merged into one or more derived classes. The relationships between classes can be illustrated as trees, and any 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 largely depends on the language in which it is written. C++ allows for multiple inheritance, so you can create complex hierarchies with multiple roots and multiple trees that blend into each other. Java®, on the other hand, is limited to single inheritance, so its class relationships are generally simpler, built as relatively self-contained trees with a single root. Interface inheritance can add complexity to a class hierarchy in Java®, but interfaces are almost never called in a framework as complex as joining trees.
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 can also be used. Depending on the language of the computer, 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 and fast rules about where particular types of classes should be placed in a hierarchy. Any class can conceivably be one of the types mentioned above. In general, the last classes in the hierarchy that have no underlying derived classes should be public and concrete. However, since purely abstract class hierarchies can also exist, this is only a rule of thumb.
While a class hierarchy can be a useful tool for organizing your code and encapsulating functionality, there may be times when digging too deep into a hierarchy can actually confuse your code, rather than clarifying it and making it easier to maintain. Building a solid relationship between many classes takes some foresight; while it may be easier to break your code into many small pieces initially, these small pieces may become more difficult to manage later. When built correctly, a class hierarchy helps both developers and users determine how classes work. If it’s built with no maintenance and clarity in mind, the many layers of inheritance can be confusing to look back on and figure out.
Protect your devices with Threat Protection by NordVPN
