Introducing:
- Delphi’s VCL class hierarchy.
- Navigation (linkage) between objects.
- Navigation on a UML class diagram.
- Visibility for message passing.
Example 2.4 Global and Local Declarations
Notice that with any RAD generated form, the unit defining the class (form) also declares a global reference to an instance of that class in its interface section.This makes it possible for any unit to access any form declared in another unit provided the appropriate uses clauses are in place. To illustrate encapsulation, we can move the global declaration in Unit4 into the implementation section to see what happens (lines 12–13 below). (The implementation section is accessible only to this unit.)
1 unit Unit4;
2 interface
3 uses
4 Windows, Messages, SysUtils, Variants, Classes, Graphics,
5 Controls, Forms, Dialogs, StdCtrls, Buttons, ComCtrls, Unit2;
6 type
7 TForm4 = class(TForm2)
8 procedure Button1Click(Sender: TObject) ;
9 end;
10 implementation
11 uses Unit1;
12 var
13 Form4: TForm4;
14 {$R *.dfm}
15 procedure TForm4.Button1Click(Sender: TObject) ;
16 begin
17 Form1.Top := 300;
18 end;
19 end. Even though Unit1 has Unit4 in its uses clause, Unit1 sees Form4 as an undeclared identifier because Form4 is now declared in Unit4’s (private) implementation section and not in its (public) interface section.
To emphasise that a declaration in the implementation section is only for a unit’s local use, Delphi generates a warning that variable Form4 is declared but not used in Unit4. Restore the variable declaration to its rightful place before the implementation keyword and the program functions correctly again.
Although we showed inheritance for extension and inheritance for specialisation separately in examples 2.3 and 2.4, they often appear in combination. OO programs typically involve quite a sophisticated network of derivation (through inheritance and composition) and communication (through association).
Example 2.5 Hierarchies and Generalisation
Both extension and specialisation work from the perspective of an existing class that we reuse to meet a new requirement by extending and/or specialising it in some way.Hierarchical generalisation, on the other hand, looks at what is shared between a number of existing classes (ie what is general between them) and then moves this common code out of the existing classes into a superclass. By generalising these shared characteristics up into a superclass from which the subclasses inherit, these shared characteristics need to be coded only once, in the superclass, and can then be reused by the subclasses. Often the superclass, like TForm2 in the previous examples, is not even instantiated but serves instead simply as a way of storing the characteristics shared by its subclasses.
The mechanisms for both extension and specialisation and for generalisation are much the same and the distinctions between these usually result from a particular set of circumstances. Extension or specialisation often starts with an existing class which is modified in some way to meet a new requirement. Generalisation often starts with the identification of common characteristics between subclasses and results in the creation of a possibly ‘artificial’ superclass containing these shared characteristics.
Just as, in the previous examples, we can say that TForm3 and TForm4 either extend or specialise TForm2, we can equally say that TForm2 generalises TForm3 and TForm4 since TForm2 embodies the operations and data that are appear in both TForm3 and TForm4 (except where TForm4’s Button1Click method overrides TForm2’s Button1Click). So when we analyse a system and find a group of objects it is worth looking out for data and behaviour that different objects share and then generalising this data and behaviour up the hierarchy to gain the benefits of reuse.