This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 What Are Patterns?
We based our pattern style on Christopher Alexander's work (1977, 1979) on pattern languages. His patterns capture just the information we need, and in a highly readable form. Each pattern indicates what is present in a good example, what sorts of thoughts or trade-offs push the writer toward and away from a good result, our recommendation for dealing with them, and examples of these ideas in action.
Alexander, a building architect, recognized common structures in cities, communities, and buildings that he considered to be "alive." His research resulted in the creation of what he called a language, one he believed would enable people to design almost any kind of building and community, a language based on the way that people resolved those forces that show up over and over again, in building situations all over the world. He called these recurring themes patterns.
Alexander wrote: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you could use this solution a million times over without doing it the same way twice" (Alexander 1977, p. x). Alexander intended that patterns answer questions such as "Where should I place a terrace?" "How should I design the front entrance?" or even "How should I organize my community?"
Alexander wrote a five-hundred-page book to describe what a pattern is. The one-sentence version might be this: "A pattern is a three-part rule that expresses a certain relationship between a certain context, a problem, and a solution" (Alexander 1979, p. 247). Like a rule, a pattern has a problem, and then proposes a solution to the problem. The context helps us understand when the solution to the problem is appropriate.
Alexander's patterns never really caught on in the architectural community, but they became the rage in the software development community around 1995, with the publication of the book Design Patterns: Elements of Reusable Object Oriented Software (Gamma et al. 1995). This book used patterns to capture good solutions to common problems programmers experienced when designing software. Of course, like any worthwhile idea in technology, shortly thereafter, pattern-hype grew out of control, propelling patterns as the next magic bullet for all software development.
It is time to get patterns back to their appropriate place: as signs of quality, and as strategies. When used as a sign of quality, a pattern expresses what is present in a well-formed example (of whatever is being discussed). For instance, when lighting a room, Alexander's Light on Two Sides of Every Room states that people are instinctively drawn to rooms that have natural lighting on two or more walls (Alexander 1977). An example in this book, for use cases, is VerbPhraseName (p. 122), where the name of a use case is a verb phrase describing the intention of the primary actor. When used to capture a strategy, a pattern names a way to deal with conflicting pressures. An example in software design from Design Patterns is Visitor, which describes how to traverse complex data structures without changing the class of the object being traversed (Gamma 1995). An example from software project management is Cockburn's Gold Rush: When you don't have time to capture requirements completely and then design the program carefully, do them in parallel, carefully monitoring communication and rework issues (Cockburn 1998).
Patterns as signs of quality are aids for diagnosing, revising, and improving a group's work. Patterns as strategies help people thread their way through complex situations. These two contributions of the pattern form should not be lost amid the hype over the term.
Although we like the form of Alexander's pattern writing, it is our experience that people can become confused by the word pattern. That word often brings to the listener's mind repeating visual designs on ties, carpets, and wallpaper. Even today, some people who are familiar with the concept of software patterns think of them as plug-and-play solutions. They fail to realize that a pattern is often part of a larger, more comprehensive language. In neither case do readers get a clear indication of what they might encounter in the book, nor do they get the connection to quality that we are after.
Despite these reservations about the word patterns, we chose to write our handbook using the pattern form rather than as simple heuristics or rules. A guideline or rule says only "do this," without exploring the alternatives and their ramifications, while the pattern form supports that discussion. Equally important, a pattern introduces phrases in a vocabulary, phrases that allow people to shorten long discussions. Often, that phrase is all that is left of the pattern in a person's mind—which is quite fine. People who have read Design Patterns simply say "Visitor" and understand the trade-offs and issues the pattern entails. We hope the readers of this book will be able to simply say, "CompleteSingleGoal" (p. 118), "ExhaustiveAlternatives" (p. 129), or "TwoTierReview" (p. 64) and similarly understand the corrections and discussions involved.
There is one final relationship between the entries in this handbook and Christopher Alexander's original pattern language: the individual entries do not stand alone, but lead to each other. We keep finding a remarkable similarity between Alexander's discussion of the relationship between cities, single buildings, and building components and our own discussions of sets of use cases, single use cases, and the components of use cases. We discovered, for example, that considering only the entries below the level of a single use case, we were still missing critical signs of use case quality. We needed to consider the larger level of discussion to find the missing entry (for example, this is how we identified UserValuedTransactions [p. 95]). While this similarity between our work and Alexander's is not at all critical to the use of this handbook, we trust that aficionados of Christopher Alexander's pattern languages will enjoy the similarities.