Introduction
Nearly all the communication between objects covered so far has been unidirectional, from an initiator to a recipient. This leaves the recipient with no possibility of using its own initiative to solicit any information it may need from the initiator, a problem we address in this chapter.Requesting Additional Information
The Role–Player pattern in chapter 11 requires that the different roles all implement the same interface that is set by the abstract base class.But what happens if our new category represents hourly paid employees? Hourly paid employees clock in and out and work a variable number of hours each month. So we need both their notch and the number of hours they have worked in order to calculate their earnings. TCategory’s existing interface, the GetPackage method, transfers only the notch and not the number of hours.
We could change the GetPackage method signature to include Hours. But the TCategory hierarchy must have pure subtyping for the program to work, and so if we make any changes we must make them in the (abstract) base class TCategory, and all its descendants must then implement this change. TTrainee, TWeekly and TMonthly are not interested in the Hours and so redesigning the whole hierarchy to accept an additional Hours parameter for the sake of only one subclass is clumsy and reduces the overall cohesion.
It seems then that the user interface can’t (elegantly) tell THourly what the number of hours is, so we must find a way for THourly to request this information. This is a move away from a push communication strategy to a pull strategy where the recipient object can take responsibility for its information needs by requesting the data it requires.
Read the full chapter in the provided PDF...
The Sender parameter and Callbacks
We can establish a communication channel between THourly and TfrmPayment that keeps to the ‘neighbours only’ rule by setting up a series of bidirectional links. TfrmPayment will identify itself to TEmployee. TEmployee in turn will identify itself to TCategory. (This makes the linkage dynamically configurable rather than hard coded, and simplifies reuse.) When THourly requires additional data, it will request this data from TEmployee. TEmployee will delegate this request to TfrmPayment and then supply the resulting data to THourly.Read the full chapter in the provided PDF...
Bidirectional linking: the problem of a circular reference
When one class refers to another class, it must refer to the other unit in its uses clause. So when we have classes in different units referring to each other, each unit must list the other unit in its global uses clause. Doing this, however, sets up a circular reference that the Delphi compiler rejects.Read the full chapter in the provided PDF...
Chapter Contents
- Introduction
- Requesting additional information
- The Sender parameter and Callbacks
- Bidirectional linking: the problem of a circular reference
- Identifying one object to another
- Example 12.1 Bidirectional linking and the Sender parameter. Disclosing an object’s identity; Circular referencing; Downcasting.
- Example 12.2 Callback. Providing a data access method; Using the callback.
- Patern 12.1 The SenderArgument Pattern
- Link through the root
- Example 12.3 Linking through superclasses. Linking to subtypes; Defining the new recipient subtypes.
- Example 12.4 Inheriting a link. User interface subclasses.
- Example 12.5 Providing additional data to a role. Adapting TCategory; Modifying TEmployee; The base form for the user interface; The new user interface.
- Callback methods
- Example 12.6 Two way communication between classes in the same unit
- Example 12.7 A linking class
- Homework Problems
