10.2 Transitivity Among Design Transformation Patterns

Consider the following transformation pattern, which I have named the interrupt pattern. It handles a common design problem that occurs in interrupt-driven architectures.

The Interrupt Pattern

Source Pattern.

Many systems have interrupt-driven devices or algorithms that, when modeled, result in a design in which the class representing the interrupting device needs to send a message to its containing class. Almost by definition, an interrupting device is interrupting something at a higher level in the system.

Motivating Heuristic

Contained objects should never send a message to the objects that contain them.

Rationale.

If a contained object is dependent on the class that contains it, then it is not reusable. If the card reader of an automatic teller machine has knowledge that it is contained in an ATM, then it cannot be taken out of the ATM and used to build a security door. If an alarm clock is dependent on its containing bedroom, then we cannot take it out of the bedroom to build a time lock safe.

Target Pattern.

When a contained object must send a message to its containing class, then the containing class should be made more general through judicious use of inheritance. In this way, the contained object does not depend on the containing class, only on its base class. It is easier to require a reuser to inherit from some abstract class than to use a particular class (effectively ruining any chance of reuse outside of the original domain).

These patterns capture interesting design transformations and also have interesting properties of their own. The broadcast and interrupt patterns are transitive. The target of the broadcast pattern is equivalent to the source of the interrupt pattern. Used together, the two patterns improve the design in a two-step process. While this sounds weaker than transitivity, it actually states that "If there exists a design transformation pattern to take a design from A to B and there exists a design transformation pattern to take a design from B to C, then there exists a design transformation pattern to take A directly to C." We do not necessarily document this third pattern, just as we do not document an inheritance relationship achieved through transitivity. It is, nonetheless, a transitivity relationship. This transitivity can be continued through a third pattern, which takes the target of the interrupt pattern as its source.

The Interrupt-Polling Pattern

Source Pattern.

Designs that model interrupt-driven devices and algorithms often require the object modeling the interrupt-driven device to send a message to its containing class. This architecture is often made more flexible by having the containing class abstracted to some base class via inheritance.

Motivating Heuristic.

A designer should minimize the number of collaborations in his or her design.

Rationale.

Each time a uses relationship is added to an object-oriented design, the complexity of the system increases. This complexity attacks the understanding of the system by its architects as well as harms the reusability of classes by increasing the dependency of the class sending the message.

Target Pattern.

The architecture of an object-oriented design should attempt to exploit the existing uses relationships rather than create new ones. The system should resort to a polling architecture rather than the interrupt-driven architecture of the source pattern. In this way, the containing class can poll the contained, interrupting object. The contained object has no dependency on its container, and we eliminate one uses relationship from the architecture.

It is important to note that there are physical design trade-offs between the interrupt pattern and the interrupt-polling pattern. A particular application may not be able to afford the extra cost of polling in its particular domain. In this case, the designer is forced into a worse (i.e., more complex) logical design for physical design reasons. Most domains require such concessions from its designers for one reason or another, such as object designs interfacing to existing action-oriented systems, or languages that are not expressive enough to capture the necessary facets of design.