14.3 Delegation of Control

Not all state machines participate equally in the dynamics of a domain. In planning a system of more than a few state machines, we need to delegate responsibilities to the various state machines.

14.3.1 Hierarchical Delegation

Some state machines tell others what to do and get an immediate response. For example, the order tells the credit card charge to make a charge, and the order receives an immediate response indicating success or failure. Similarly, the shipment makes a request to the delivery company and receives a response first to assign a tracking number and then to confirm delivery. These examples of hierarchical control can be seen in Figure 14.8.

Figure 14.8. Bookstore Collaboration

14.3.2 Networked Delegation

Hierarchical delegation expects responses from the state machine it controls. By contrast, networked delegation does not require a response from the state machine under control. For example, the order delegates to the shipment assigner to indicate the order is ready to ship. The next thing the order finds out is that the order has actually been delivered. The order does not need to interpose itself, like an interfering manager, at every step.

The precise flow of control is illustrated by the table in Figure 14.9.

Figure 14.9. Activities and Signals

The effect of this delegation is that the order statechart diagram does not deal with the details of how the order's contents are packed and shipped. As far as the order is concerned, once the credit card charge is approved, the order is on its way until its delivery is confirmed.

Another example of networked delegation is the sequence that notifies the delivery company to pick up the shipment, but the shipping clerk actually records that the shipment was picked up.

Deciding whether to use hierarchical delegation or networked delegation, or for that matter, deciding who is in charge, is not always an easy task. However, there are no wrong answers. The best approach is to sketch something out and see which is simpler. The diagrams are also planning tools for organizing the state machines in a domain.

14.3.3 Distributing Control in Associations

An especially knotty situation occurs when two classes are apparently at the same level of control. In the examples above, it's clear the shipment is subordinate to the order and the charge and that the selection is a part of the shopping cart, so the shopping cart cannot complete until all the selections are made. But it's not at all clear a clerk should seek out customers, rather than having customers seek out clerks. To use another example, should the cow demilk itself or the milk decow itself?^[2]

^[2] This delightful example is due to Meilir Page-Jones [2].

The answer is neither. The best way to model this situation is to construct an association class, Milking, between the cow and the batch of milk and have the association class manage the control. After all, it is the milking that has the behavior. In some sense, the cow and the milk are unwilling participants.

Similarly, in the case of the customer and clerk, we build an association class, Service, that manages the association. In this case, there is also contention for clerks if we empower the customer, and for customers if we pay the clerks' commission, as described in Chapter 13: Relationship Dynamics.