Introducing (in this Chapter): :
- Clarify differences between subclassing and subtyping.
- Use each appropriately.
Introduction
Over the last few chapters we have been looking at inheritance, both subclassing andsubtyping. Programmers often do not distinguish between these two forms since they are implemented in similar ways and are often used in combination. However subclassing (class or implementation inheritance) can easily be overused and subtyping (interface inheritance)can easily be underused. Because of this we lose potential benefits of OO and develop systems that are more rigid and error prone than they need to be.In this chapter we distinguish between these two forms of inheritance and look at some common errors in using them.
Implementation inheritance
Implementation inheritance is an alternative name for subclassing or class inheritance. It is useful as a name because it emphasises that we use it in order to derive one class from another. It creates a hierarchy where the new class inherits the implementation (ie the structure & behaviour) from another class, allowing the programmer to reuse existing code. The subclass therefore needs only to implement differences from the superclass, which it does by overriding or extending the inherited implementation. The purpose of implementation inheritance is therefore code reuse.In using implementation inheritance, an important perspective to keep in mind is that it implements the IsA (or KindOf) relationship. This has a number of important consequences, and breaking the IsA relationship is one of the main reasons for inappropriate use of inheritance.
Because of inheritance, the Child IsA Parent. This means that the child has the same innate character as the parent and is not merely a role of the parent. It is the entire parent plus more: the child has all the attributes and behaviour of the parent plus additional attributes and behaviour of its own. Because the child has these additional attributes and behaviour it is more tightly specified than the parent and so is a specialisation of the parent.
Typical uses of implementation inheritance that accord with the IsA relationship are subclassing for extension and specialisation, and for creating a generalisation hierarchy.
Extension
In inheritance for extension, the child adds new functionality without making any changes to the parent’s existing functionality. In figure 1, this corresponds to the More Data and More Methods of SubClass1, and to the Other Data and Other Methods of SubClass2. (We introduced this concept in example 2.2 in the context of VFI: example 2.2 step 1 adds a CheckBox while example 2.2 step 2 adds an UpDown.) While inheritance for extension offers considerable potential for code reuse, if it is overused it leads to very deep, rigid hierarchies that are difficult to modify.Specialisation
In inheritance for specialisation, the child is a special case of the parent and so overrides some of the parent’s methods as in Override Methods 1 and 2 that override the Parent Class’s Methods in figure 1. There are two forms of overriding. The one simply specialises the parent’s method. It invokes the method it is overriding in the parent (using the inherited keyword in Delphi) and then adds some additional operations. (We introduced this concept in example 2.3 in the context of VFI. We saw another example of this in example 4.2 step 1 where the subclass’s constructor first invokes the superclass’s constructor before initialising its additional data fields and uses the superclass's destructor after showing a message.) The other form of specialisation is where the overriding method completely replaces the parent’s method. We saw this in example 6.1, where the subclasses’ GetKind methods completely replace the superclass’s GetKind method.Because of the hierarchy, a subclass can substitute for a superclass. So we must be very careful when overriding parent methods to make sure that the child can still operate satisfactorily in the place of the parent even with its overriding methods. If the overriding destroys the parental type by introducing inappropriate behaviour, substitution is no longer valid semantically and we have a potentially error-prone situation in the code. (Anti-pattern 7.2, in the next chapter, returns to this issue.)
