Interface inheritance
With implementation inheritance we reuse the superclass’s implementation. In contrast to this, interface inheritance, which we cover in this section, reuses the supertype’s interface (or signature or type). However, it does not reuse the implementation, since each subtype implements this interface differently according to its own needs. We saw an example of this in example 6.4, where we have an abstract class TMyShape. TMyShape defines the procedure Draw(), but does not implement it. The subclasses TMyEllipse and TMyRectangle each implement Draw() differently. The client class, in this case the user interface, simply sends a Draw() message to a TMyShape. Through polymorphic substitution, either a TMyEllipse or a TMyRectangle can respond appropriately to this Draw() message.The abstract superclass acts as a type specification, and so has abstract methods. Since these methods are specifying an interface, they are virtual: they have no implementation in the parent and the parent cannot be instantiated. The concrete subclasses override the Abstract Methods() with their Concrete Methods() and so can be instantiated.
In summary, the child classes inherit the (abstract) class signature of the superclass. They provide concrete methods of the same type as the abstract methods, but each child class has its own, usually different, implementation.
Example
Let’s look at how one might decide to use interface inheritance while designing a system. Take a system where specific benefits differ between monthly paid and weekly paid workers although the general principles of vacation leave, study leave and sick leave apply to both groups.Monthly Benefits: CalcLeave(), CalcStudyLeave(), CalcSickLeave()
Weekly Benefits: CalcLeave(), CalcStudyLeave(), CalcSickLeave()
In object modelling terms, both of these have the same interface (or type) but have different implementations of the operations. To introduce the possibility of subtyping, we create an abstract type specifying the interface and leave the concrete implementations to the subtypes: TBenefits. All three methods in TBenefits should be abstract, and each of MonthlyBenefits and WeeklyBenefits must override (thus implement) all three methods.
This inheritance structure is designed with substitution in mind since either subtype can meaningfully substitute for the supertype. So client objects program to the supertype interface specification even though it is abstract and has no implementation. At runtime, one of the subtypes substitutes for the supertype and performs the required operations. We use interface inheritance when classes have the same kinds of operation, and so have a consistent interface, but the details of the operations are different. Through dynamic binding the behaviour depends on the runtime identity of the class currently substituting for the supertype, giving rise to polymorphism.
That's it for this (theorethical) chapter. Next time: Inheritance anti-patterns: Abuses of implementation inheritance
