[ fromfile: inheritance-intro.xml id: classdesign ]

Sometimes defining an inheritance relationship helps at first (e.g., by reducing redundant code) but causes problems later when other classes must be added to the hierarchy. Some up-front analysis can help make things easier and avoid problems later.

Example 6.14, in which we derive from the abstract Shape class, demonstrates an inheritance relationship with two levels of depth. The Rectangle class was used as a classification of objects and also as a concrete base class.

Is a square a kind of rectangle? Geometrically it certainly is. Here are some definitions borrowed from elementary geometry.

As you attempt to represent an inheritance tree of classes for an application that you are designing, it helps to list the kinds of capabilities that you need to provide for each class. For geometric shapes, they might be

After you describe the interface in further detail, you may find that the classic geometric definitions for shape classification are not the ideal taxonomy for shape classes within the context of your application.

As you perform an analysis some questions arise:

Using a UML modeling tool makes it easier to try out different ideas before writing concrete code. UML diagrams are especially useful for focusing on and describing small parts of a larger system. Figure 6.4 has concrete classes that serve as templates for creating the more "specific" shapes.

Figure 6.4.  Another Way to Represent Shapes

In this tree diagram, the classes in leaf nodes are constrained versions of their base classes. The interface for the vector representations, drawing, and loading/saving of the objects is established in the abstract base classes.