The Project Browser
Neither the Code Explorer nor the Object TreeView shows the class inheritance hierarchy, so it is also worth taking a quick look at Delphi’s Project Browser, available at View | Browser in versions of Delphi up to Delphi 7. (The project loaded must have run in the current session before the Browser option becomes available.)The Project Browser shows the classes we have created in this project along with their inheritance structure. We see TObject as the root class with TItem derived from TObject and TItemBox derived in turn from TItem. We also see that the form we have created, TfrmCount, is derived from TForm, which in turn is derived from a series of other objects all the way back to TObject.
If we select TItemBox in the left pane, in the right pane we see that TItemBox has a single public member, the method AddBox. It has inherited the private data field, FCount, and a whole lot of public methods inherited from TItem and TObject including the constructor Create near the bottom of the pane.
Example 3.4 Overloaded Methods & Protected Visibility
Some OO programmers feel that one should not access a data field defined in a superclass directly from a subclass. They would be unhappy with our definition of TBoxItem’s AddBox method in example 3.3 step 1 line 35 since this accesses directly the superclass’s FCount data field. Instead, to protect the encapsulation, they feel that a subclass should always use the superclass’s access methods to access its data fields. We could redefine AddBox in a messy and inelegant fashion to use AddItem:32 procedure TItemBox.AddBox;It would be better, though to have a method in the superclass TItem that adds a specified number of items to the FCount field. This leads to the concept of overloaded methods: add a protected method AddItem with the number to add as a parameter (line 8 below). This is in addition to the AddItem method we already had, though it had no parameters (line 10 below). So now we have two methods with the same name. How does Delphi distinguish between them? If we call AddItem without any parameters, as in example 3.2 step 2 line 31, Delphi will invoke the method with the required name and without any parameters (ie lines 20–23 below).
33 var
34 Count: integer;
35 begin
36 for Count := 1 to NoInBox do
37 AddItem;
38 end;
If we call AddItem with a single integer parameter, as in line 41 below, Delphi will invoke the method implementation with the same parameter signature (ie lines 24–27 below). To inform the compiler that we are overloading this method name, we must add the overload keyword with each different declaration of AddItem (lines 8 & 10 below). Overloaded method names must always have different parameter lists in terms of types and/or numbers of parameters so that the compiler can distinguish between their calls.
We can avoid overloading if we use different names, eg AddItem and AddItems. However in cases where we want to perform the same operation but with different parameter types, eg integers or doubles, it is particularly useful to be able to overload the same name.
1 unit ItemU;
2 interface
3 type
4 TItem = class(TObject)
5 private
6 FCount: integer;
7 protected
8 procedure AddItem (aNoToAdd: integer) ; overload;
9 public
10 procedure AddItem; overload;
11 function GetCount: integer;
12 procedure ZeroCount;
13 end;
14 // Derived from TItem, not TObject
15 TItemBox = class(TItem)
16 public
17 procedure AddBox;
18 end;
19 implementation
20 { TItem }
21 procedure TItem.AddItem;
22 begin
23 Inc(FCount) ;
24 end;
25 procedure TItem.AddItem(aNoToAdd: integer) ;
26 begin
27 Inc(FCount, aNoToAdd) ;
28 end;
29 function TItem.GetCount: integer;
30 begin
31 Result := FCount;
32 end;
33 procedure TItem.ZeroCount;
34 begin
35 FCount := 0;
36 end;
37 { TItemBox }
38 procedure TItemBox.AddBox;
39 const
40 NoInBox = 4;
41 begin
42 AddItem(NoInBox) ;
43 end;
44 end.
