_{Materials written by John Barrow. Modifications by Zarko Gajic}
Back to Chapter 16

Introducing (in this Chapter):

• Indirection through chaining and through delegation.
• Comparing chaining and delegation in terms of encapsulation and coupling.

Introduction

An important part of object orientation is the concept that a group of objects cooperate with one another to perform a particular task. To support this cooperative venture there needs to be a communication structure between the objects involved.
ObjectA can communicate directly with ObjectB if it carries a reference to ClassB as one of its data fields.


A situation may arise where ObjectA, which has a reference to ObjectB, needs to communicate with ObjectC. If ObjectB carries a reference to ObjectC, ObjectA can then communicate with ObjectC indirectly through ObjectB. This process, where one object uses a second object to communicate indirectly with a third object, is called indirection: it forms the subject of this chapter.

The easiest way to communicate indirectly is to provide public links in the intervening object(s). This is called chaining (or explicit delegation). Although easy to set up, chaining reduces encapsulation and increases coupling, both of which are undesirable.

An alternative approach to indirect communication, implicit delegation or simply delegation, maintains encapsulation and restricts coupling. However it requires more effort to program than chaining does. We?ll explore both these approaches in the following examples, a process that will culminate in the presentation of two patterns: The Law of Demeter and Delegation.

Indirection relies on one object carrying a reference to a second object. The first object uses this reference to delegate responsibility for certain behaviour to the second object. The reference acts as a one-way link between objects. If the second object needs to initiate communication with the first object, it requires a reference to the first object as one of its data fields.

This implementation principle is also the basis for composition, a concept that has already appeared several times and that we investigate in more detail in the following chapter.

An application problem: multiple counters

Counters are nice, simple, but realistic objects to use to demonstrate OO principles. Here we will look at three different ways of writing an OO program to record the number of people entering and leaving a museum and so to display the number of visitors still inside the museum. (The museum staff can use this to ensure that they do not lock anyone inside the museum when they go home for the night!)
Our criteria in this ("Museum attendance") program are to:

1. reuse whatever existing code we can,
2. distribute the responsibilities appropriately between the available objects, and
3. keep the level of coupling between objects low.

Existing code that is available for this program from a previous project is a TCounter class defined in CounterU.pas. Notice the read-only property (line 8 below).
unit CounterU;interfacetype    TCounter = class (TObject)    private      FTotal: integer;    public      property Total: integer read FTotal;      procedure Add (aNumber: integer) ;      procedure Clear;      procedure Subtract (aNumber: integer) ;    end;implementationprocedure TCounter.Add (aNumber: integer) ; begin    Inc (FTotal, aNumber) ; end;procedure TCounter.Clear; begin    FTotal := 0; end;procedure TCounter.Subtract(aNumber: integer) ; begin    Inc (FTotal, -aNumber) ; end;end. In such a simple example as this, the easiest way of coding this program is to ignore the existing TCounter class and to define a new class (called TTriCount maybe). However, as programs get bigger and bigger, re-use becomes much more urgent. So in the next few examples we look at some ways of re-using an existing class, TCounter in this case, in a new application.