Inheritance Design

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 derived from the abstract Shape class, demonstrates an inheritance relationship of two levels of depth. The Rectangle class was used as a classification of objects and also as a concrete class.

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

As we attempt to represent an inheritance tree of classes, it helps to list the kinds of capabilities that we will need to provide for each class. They would be:

After we describe the interface in further detail, the geometric definitions for shape classification may not lead to the ideal taxonomy for these shape classes.

As we 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.

In Figure 6.4, we have concrete classes that serve as templates for creating the more "specific" shapes. The leaf classes are, in some cases, constrained versions of their base classes. The vector-representation, drawing, and loading/saving of the objects is handled in the abstract base classes.

Figure 6.4. Another way to represent shapes

In the geometric sense, given a circle, one can prove it is also an ellipse, because an equation exists that specifies an ellipse, with its two foci being equal. In contrast, the diagram in Figure 6.4 shows Ellipse to be a kind of Circle, with an extra point, or an extra degree of freedom. Would it make more sense to reverse the inheritance relationship? Or to have a completely different tree? Where is the is-a relationship?

Overloading, Hiding, and Overriding

Категории