Introducing (in this Chapter):
- Substitution with programmer classes
- Early (static, compile time) binding
- Late (dynamic, run time) binding
- Virtual and override methods
In part 5 we began using inheritance differently, for substitution. An important part of substitution is that the superclass establishes a particular type. Subclasses that implement this type fully, ie that can substitute for the superclass under all conditions, are called subtypes. This may not yet be particularly clear since the example in the previous chapter, which used VCL components, concentrated on substitution.
So in this chapter we look briefly at substitution again, but in the context of programmer-generated classes. We then incorporate dynamic binding to extend substitution to the concept of polymorphism. This leads naturally to an exploration of abstract classes. The concepts of substitution, polymorphism and abstract classes are closely tied to the concept of subtyping and all three of these are important aspects of many OO patterns. For some people, polymorphism represents the heart of OO programming.
This chapter establishes the concept of polymorphism (subtyping) as distinct from reuse (subclassing). Following chapters illustrate some of the ways in which polymorphism is used and reveal why skilful use of polymorphism is one of the most important aspects of OO programming.
Example 6.1 A polymorphic program
We start this chapter by reviewing briefly the principles from the previous chapter (ie generalisation and substitution), but using programmer defined classes, and then extend these to a polymorphic program by introducing dynamic binding.We use a simple ancestor class, TFurniture, and two subclasses, TChair and TTable. (TChair and TTable are also valid subtypes of the TFurniture type.) We will create objects of different types and then send a message to each by calling a method that each type responds too. To keep the principles clear, this is a very simple example, and so these various furniture objects know only what kind they are. In a full system, say for an antique shop, they would be more complex, with a variety of methods and carrying information about their value, what wood they are made of, when they were made, and so on. But our simple GetKind access method is sufficient to introduce polymorphism.
In this example we’ll also introduce a convenient tool, called Class Completion (mentioned briefly in part 4), that speeds the creation of our own classes. So this example will cover a lot of interesting ground!
Ex 6.1 step 1 Creating the classes and types
Start a new application and add a second unit to it through the menu sequence File | New | Unit. Save this unit (called Unit2) as FurnitureU.pas and then enter the program as follows. Start with just the class declarations (lines 3–11 below). Then place the cursor on the declaration of function GetKind ... (line 6) and press <Shift+Ctrl+C> (or right-click and select Complete Class at Cursor) to invoke Class Completion. This will create a skeleton for the method. Now it is simply a matter of entering the program code (line 16). 1unit FurnitureU;
2interface
3type
4 TFurniture = class (TObject)
5 public
6 function GetKind: string;
7 end;
8 TChair = class (TFurniture)
9 end;
10 TTable = class (TFurniture)
11 end;
12implementation
13{ TFurniture }
14function TFurniture.GetKind: string;
15begin
16 Result := 'Furniture';
17end;
18end. We’ll expand these classes in a little while, but for now we need a driver to test these class definitions.