Conclusion

Overview

The catalog does not present algorithms or programming techniques that haven't been used before, give a rigorous method for designing systems, or develop a new theory of design — it documents existing designs. The authors argue that cataloging design patterns is nonetheless important: it gives standard names and definitions for the techniques designers already use. If design patterns in software are not studied, they cannot be improved, and it becomes harder to come up with new ones.

This topic sets out what the patterns actually do for the working designer. It identifies four concrete effects the catalog has on object-oriented design practice — a common design vocabulary, a documentation and learning aid, an adjunct to existing design methods, and a target for refactoring — then situates the work in its history and in the wider pattern community, beginning with Christopher Alexander's architectural pattern languages. The book is described by its authors as "only a start": a collection of the most common patterns expert object-oriented designers use, intended to mark the start of a movement to document the expertise of software practitioners.

Key takeaways

Mental model

Copy sourceZoom

What to expect from design patterns

The authors list several ways the patterns affect how you design object-oriented software, based on their day-to-day experience.

A common design vocabulary

Studies of expert programmers in conventional languages have shown that knowledge and experience isn't organized simply around syntax, but in larger conceptual structures such as algorithms, data structures, and idioms, and in plans for fulfilling a particular goal. Designers don't think about the notation they use for recording a design so much as they try to match the current design situation against plans, algorithms, data structures, and idioms they have learned in the past.

Computer scientists name and catalog algorithms and data structures, but rarely name other kinds of patterns. Design patterns provide a common vocabulary for designers to communicate, document, and explore design alternatives. They make a system seem less complex by letting you talk about it at a higher level of abstraction than a design notation or programming language — they raise the level at which you design and discuss design with colleagues.

Once the patterns are absorbed, the design vocabulary changes: designers speak directly in terms of pattern names, saying things like "Let's use an Observer here," or "Let's make a Strategy out of these classes."

A documentation and learning aid

Knowing the patterns makes existing systems easier to understand, because most large object-oriented systems use them. People learning object-oriented programming often complain that the systems they work with use inheritance in convoluted ways and that the flow of control is hard to follow; in large part this is because they don't understand the design patterns in the system. Learning the patterns helps in understanding existing object-oriented systems.

The patterns also make you a better designer, because they provide solutions to common problems. Given enough time with object-oriented systems you would probably learn these patterns on your own — but reading them helps you learn them much faster, helping a novice act more like an expert.

Describing a system in terms of the patterns it uses makes it far easier to understand. Otherwise people have to reverse-engineer the design to unearth its patterns. A common vocabulary means you don't have to describe a whole pattern; you can name it and expect the reader to know it. A reader who doesn't know the patterns has to look them up at first, but that is still easier than reverse-engineering.

The authors note they use the patterns in arguably naive ways: to pick names for classes, to think about and teach good design, and to describe designs in terms of the sequence of patterns applied. More sophisticated uses are easy to imagine — pattern-based CASE tools or hypertext documents — but the patterns are a big help even without sophisticated tools.

An adjunct to existing methods

Object-oriented design methods are meant to promote good design, teach new designers to design well, and standardize how designs are developed. A design method typically defines a set of notations (usually graphical) for modeling aspects of a design, plus rules governing how and when to use each notation; methods usually describe the problems that occur in a design, how to resolve them, and how to evaluate a design. But methods have not been able to capture the experience of expert designers.

Design patterns are an important piece that has been missing from object-oriented design methods. They show how to use primitive techniques such as objects, inheritance, and polymorphism, and how to parameterize a system with an algorithm, a behavior, a state, or the kind of objects it is supposed to create. They describe more of the "why" of a design rather than just recording the results of decisions — the Applicability, Consequences, and Implementation sections of each pattern help guide the decisions you have to make.

Patterns are especially useful in turning an analysis model into an implementation model. Despite many claims of a smooth transition from object-oriented analysis to design, in practice the transition is anything but smooth: a flexible, reusable design contains objects that aren't in the analysis model; the programming language and class libraries affect the design; and analysis models often must be redesigned to make them reusable. Many of the patterns in the catalog address exactly these issues — which is why the authors call them design patterns.

A full-fledged design method requires more kinds of patterns than design patterns alone. There can also be analysis patterns, user-interface design patterns, or performance-tuning patterns. But design patterns are an essential part — one that had been missing until this catalog.

A target for refactoring

One problem in developing reusable software is that it often has to be reorganized, or refactored. Design patterns help you determine how to reorganize a design, and they can reduce the amount of refactoring needed later.

Brian Foote identifies three phases in the lifecycle of object-oriented software: the prototyping, expansionary, and consolidating phases.

| Phase | What happens | Dominant kind of reuse | | --- | --- | --- | | Prototyping | Rapid prototyping and incremental change until the software meets an initial set of requirements and reaches "adolescence"; class hierarchies closely reflect entities in the initial problem domain. | White-box reuse by inheritance | | Expansion | Once in service, evolution is governed by two conflicting needs — satisfy more requirements, and become more reusable. New requirements add new classes, operations, and whole hierarchies. Eventually the software becomes too inflexible for further change and its hierarchies no longer match any single problem domain. | White-box reuse, under strain | | Consolidation (refactoring) | The software is reorganized: classes are torn apart into special- and general-purpose components, operations move up or down the hierarchy, and class interfaces are rationalized. This is the phase in which frameworks often emerge. Many new objects are produced, often by decomposing existing objects and using object composition instead of inheritance. | Black-box reuse replaces white-box reuse |

The continual need to satisfy more requirements together with the need for more reuse propels object-oriented software through repeated cycles of expansion and consolidation — expansion as new requirements are satisfied, consolidation as the software becomes more general. This cycle is unavoidable. But good designers are aware of the changes that can prompt refactorings, and they know class and object structures that help avoid them; their designs are robust in the face of requirement changes. A thorough requirements analysis highlights the requirements most likely to change over the software's life, and a good design is robust to them.

The patterns capture many of the structures that result from refactoring. Using them early in a design prevents later refactorings; even if you don't see how to apply a pattern until after the system is built, the pattern can show you how to change it. Design patterns thus provide targets for your refactorings.

A brief history

The catalog began as part of Erich Gamma's Ph.D. thesis; roughly half of the current patterns were in it. By OOPSLA '91 it was officially an independent catalog, with Richard Helm joining Erich; John Vlissides started soon thereafter, and by OOPSLA '92 Ralph Johnson had joined. A 90-page paper prepared for ECOOP '93 was too long to be accepted, so the authors summarized the catalog, submitted the summary (which was accepted), and decided shortly afterward to turn the catalog into a book.

Several pattern names changed along the way: "Wrapper" became "Decorator," "Glue" became "Facade," "Solitaire" became "Singleton," and "Walker" became "Visitor." A couple of patterns were dropped as not important enough, but the set of patterns in the catalog has changed little since the end of 1992 — though the patterns themselves evolved tremendously.

Noticing that something is a pattern is the easy part; it is easy to spot patterns when you look at enough systems. Finding patterns is much easier than describing them. The hard part is describing a pattern so that people who don't already know it will understand it and see why it matters. Experts recognized the value of the catalog in its early stages, but the only ones who could understand the patterns were those who had already used them.

Because one of the book's main purposes was to teach object-oriented design to new designers, the authors had to improve the catalog. They expanded the average size of a pattern from under 2 pages to more than 10 by including a detailed motivating example and sample code, and began examining trade-offs and the various ways of implementing each pattern — making the patterns easier to learn. Another change was a greater emphasis on the problem a pattern solves: it is easiest to see a pattern as a solution, harder to see when it is appropriate. In general it is easier to see what someone is doing than to know why, and the "why" for a pattern is the problem it solves. Knowing a pattern's purpose helps in choosing patterns to apply and in understanding existing systems — so a pattern author must determine and characterize the problem the pattern solves, even if that characterization comes after the solution was discovered.

The pattern community

The authors place their work within a larger community interested in patterns in general and software-related patterns in particular.

Alexander's pattern languages

Christopher Alexander is the architect who first studied patterns in buildings and communities and developed a "pattern language" for generating them; his work repeatedly inspired the authors. The two bodies of work are alike in several ways: both are based on observing existing systems and looking for patterns in them; both have templates for describing patterns (though the templates differ); both rely on natural language and many examples rather than formal languages; and both give rationales for each pattern.

They differ in just as many ways:

1. People have been making buildings for thousands of years, with many classic examples to draw upon. Software systems have been made for a relatively short time, and few are considered classics.
2. Alexander gives an order in which his patterns should be used; the design-patterns authors do not.
3. Alexander's patterns emphasize the problems they address, whereas design patterns describe the solutions in more detail.
4. Alexander claims his patterns will generate complete buildings. The design-patterns authors do not claim their patterns will generate complete programs.

When Alexander claims you can design a house simply by applying his patterns one after another, his goals resemble those of object-oriented design methodologists who give step-by-step rules. Alexander doesn't deny the need for creativity — some patterns require understanding the living habits of the people who will use the building, and his belief in the "poetry" of design implies expertise beyond the pattern language itself — but his account of how patterns generate designs implies that a pattern language can make the design process deterministic and repeatable.

The Alexandrian point of view helped the authors focus on design trade-offs — the different "forces" that shape a design — and made them work harder to understand the applicability and consequences of their patterns. It also kept them from worrying about a formal representation of patterns: such a representation might make automating patterns possible, but at this stage it is more important to explore the space of design patterns than to formalize it.

From Alexander's point of view the patterns in the book do not form a pattern language. Given the variety of software people build, it is hard to see how a "complete" set could offer step-by-step instructions for designing any application — feasible for certain classes of applications (report-writing, forms-entry systems), but not in general. The catalog is a collection of related patterns, not a pattern language. The authors think it unlikely there will ever be a complete pattern language for software, though a more complete one is certainly possible; additions would include frameworks and how to use them, user-interface design patterns, analysis patterns, and other aspects of developing software. Design patterns are just a part of a larger pattern language for software.

Patterns in software

The authors' first collective experience studying software architecture was an OOPSLA '91 workshop led by Bruce Anderson, dedicated to developing a handbook (the authors suspect "architecture encyclopedia" is the more appropriate term) for software architects. That workshop led to a series of meetings, most recently the first conference on Pattern Languages of Programs in August 1994, creating a community of people interested in documenting software expertise.

Others have shared this goal. Donald Knuth's The Art of Computer Programming was one of the first attempts to catalog software knowledge, though focused on algorithms and ultimately too great a task to finish. The Graphics Gems series is another catalog of design knowledge that also tends to focus on algorithms. The Domain Specific Software Architecture program sponsored by the U.S. Department of Defense concentrates on gathering architectural information, and the knowledge-based software engineering community tries to represent software-related knowledge in general.

James Coplien's Advanced C++: Programming Styles and Idioms also influenced the authors; its patterns tend to be more C++-specific and lower-level, with some overlap noted in the catalog. Kent Beck was among the first in the software community to advocate Alexander's work and began a column on Smalltalk patterns in The Smalltalk Report in 1993. Peter Coad had also been collecting patterns, mostly analysis patterns. Several other books on patterns were in the works, one of them from the Pattern Languages of Programs conference.

An invitation

The authors close with three calls to action for readers interested in patterns:

1. Use them and look for more. Use the patterns, and look for other patterns that fit the way you design. Develop your vocabulary of patterns and use it — when talking with others about your designs, and when you think and write about them.
2. Be a critical consumer. The catalog is the result of hard work, including feedback from dozens of reviewers. If you spot a problem or want more explanation, give the authors feedback — and do the same for any other catalog. One of the great things about patterns is that they move design decisions out of the realm of vague intuition: authors can be explicit about the trade-offs they make, which makes it easier to see what is wrong and to argue with them.
3. Write down the patterns you use. Make them part of your documentation and show them to others. You don't have to be in a research lab to find patterns — but finding relevant patterns is nearly impossible without practical experience. Feel free to write your own catalog, with someone else's help to beat the patterns into shape.

Related lessons