On the previous page we are calling the Add method of the VEntered object that is a data field of the MuseumCount object. So even though the user interface object no longer has any direct access to the counters, it accesses them indirectly, through the intermediate object.
In this event handler, all the references to the TCounter objects’ methods use chaining through the intermediate object. (An alternative notation, which simplifies typing a bit, is to use a with...do construct as in btnLeave’s event handler, but we are still accessing the counters through MuseumCount and so still using chaining.)
We introduced the intermediate object so that the user interface can work with a single object and so match the physical problem more closely. This single intermediate object is simple to create since it does not itself do any of the data manipulation but instead reuses the existing TCounter class.
But does this version of the program actually meet our design goals? No, since in this version, like the version before it, the user interface is still intricately bound up with the application logic. (This breaks the third criterion, reduced coupling, given in the introduction before this example.)
Despite the intermediate object, the user interface must still add and subtract directly from the various counters. The same problems remain as in the previous version and this approach has not managed to separate the application logic from the user interface.
In a sense the situation is even worse than previously, where the user interface interacted directly with the individual counters, since it now interacts with both the intermediate object and the counters, and the coupling in the program is now higher than before. To allow communication between the user interface and the counters, the intermediate object exposes its internal structure by making its data fields public. This leads to significant encapsulation leakage since the user interface must ‘know’ the internal structure of the TMuseumCount class. Even though the user interface object has no direct reference to TCounter, it must still know about its methods too.
Let’s reconsider the situation. To reduce the chance of error (and to simplify changes in the future) we do not want the user interface to be responsible for keeping the various counters synchronised. We want the user interface class to interact only with a single TMuseumCount object and not with any TCounter objects, whether directly or indirectly.
Ideally it should be unaware that there are TCounter objects in the system. If we classify TfrmAttendance and TMuseumCount as neighbours, and TMuseumCount and TCounter as neighbours, we can state as a design goal that objects should communicate only with their neighbours. Since TfrmAttendance and TCounter are not neighbours, they should not communicate explicitly with each other Indirection whether directly or indirectly.
They should not even be aware of each other’s existence. (This is a simplified version of the ‘Law of Demeter’ which in effect says: Communicate only with neighbours.) In the next example, we’ll take a slightly more sophisticated approach and use delegation instead of chaining and then look at the benefits it offers to see how it measures up against these various criteria, namely code reuse, shared responsibilities and minimal coupling.
This concludes chapter 17.
In the next chapter we will move from chaining to delegation (or forwarding). Delegation overcomes the encapsulation leakage that is inevitably part of chaining.
