10.1 Heuristics Versus Patterns

At a workshop during OOPSLA '87, Kent Beck first brought up Christopher Alexander's text, A Pattern Language [20, 21]. In this text, Alexander attempts to capture the subconscious aesthetic qualities of architecture by using an invented pattern language. Beck suggested that we look for something similar to capture interesting patterns in good object-oriented design. Recently, a large amount of effort has been applied to this topic by Kent Beck, Richard Helm, Erich Gamma, Ralph Johnson, Bruce Anderson, James Coplien, Grady Booch, Frank Buschmann, Robert Martin, and many others. These researchers have examined patterns from many different angles, ranging from Anderson's "null object pattern," which examines a common solution to a multiparadigm language problem, to James Coplien's examination of corporate infrastructure patterns that lead to good product development.

All of this research has led me to wonder, "What is the exact relationship between the qualitative heuristics I have collected/developed and design patterns?" They are obviously related, in that the method I have used to find a good design heuristic is to find "trends" that various developers from different domains have followed. If these trends lead to designs that exhibit a desirable quality (e.g., easy to extend, easy to maintain, less complex to understand), then I try to generalize them to some rule. However, what occurs more often is a recurring trend that exhibits undesirable qualities. These need to be generalized to some design transformation pattern, namely, a pattern that captures the method by which a bad design is transformed into a good design.

Upon further examination, I have found that qualitative heuristics not only lead to a number of interesting patterns, but also exhibit some interesting properties between these patterns. A heuristic forms a gateway through which a designer can move from a bad design pattern to a good design pattern. The pattern description that captures this information consists of a source design pattern (the bad pattern), a motivating (i.e., violated) heuristic with its rationale, and a target design pattern (the good pattern). These transformation patterns (dare I call them metapatterns?) exhibit properties of transitivity and reflexivity.

An interesting problem that many of the patterns researchers have glossed over in their published literature is how a novice designer will know when a particular pattern should be applied. In some of the existing literature, the authors imply that a pattern can be applied intuitively by a design group that has been exposed to a catalog of patterns. When a pattern takes tens of pages of text to describe it, it is very unlikely that the designer will intuitively discover when the pattern is needed. Heuristics, on the other hand, are very easy to remember since their descriptions are rarely more than two sentences long. In fact, some preliminary research indicates that violations of at least two-thirds of the design heuristics described in this book could be automatically detected through the design information contained in an object-oriented case tool. As of the writing of this book, for example, at least two case tool vendors have discussed the addition of a heuristics engine to their tools. Once a designer realizes a heuristic is violated, he or she could look at a number of design transformation patterns associated with that heuristic. Each pattern would optimize the transformation for some attribute of design, for example, flexibility or minimization of classes. Some patterns may even take physical design trade-offs into consideration, such as efficiency considerations between polling and interrupt-driven architectures.

As a first example of a design transformation pattern, consider the following pattern, which I call the broadcast pattern. This pattern captures a common problem that occurs when a designer is required to share an object among a group of additional objects. The additional objects all contain the shared object by reference. The problem with this design pattern is that if one object updates the shared object, then all of the other containing objects have their state changed without a message being sent to their public interface. This can make program tracing more difficult. The solution is to have the contained object broadcast a state-change message to each of the containing objects, informing them of the update.

The Broadcast Pattern

Source Pattern.

It is common for an object-oriented design to require a number of objects to contain (by reference) the same object. This requirement may exist to save the space/time of maintaining multiple copies of an object, or to better implement referential integrity constraints that are complicated by multiple storage of the same entity, or to model in the real world an intrinsic part of the system.

Motivating Heuristic.

The state of an object should not be modified except through a message sent to its public interface.

Rationale.

If an object outside the lexical scope of another object can change the second object's state, then the cost of maintaining the system is increased. This increase is similar to the problems associated with side effects due to public data in a class or, to a less extent, to global data.

Target Pattern.

When a group of objects contain the same object (by reference) in order to support better efficiency, easier maintenance of data integrity semantics, or the implementation of a system requirement, then the shared object should broadcast a state-change message to each of the containing objects whenever its state changes.

It is important to note that both the source and target patterns are shown as an abstract example along with two specializations of the abstract example in two different domains. This is to prove that the pattern is not just a domain-specific design/ programming trick; it applies to numerous domains without regard to the specifics of the domain. Given that there are over 60 qualitative heuristics for object-oriented design, and that each heuristic denotes at least one transformation pattern, there are many of these patterns to document.