Design Patterns: Abstraction and Reuse of Ob ject-Oriented Design 1? 2 3 2 Erich Gamma , Richard Helm , Ralph Johnson , John Vlissides 1 Taligent, Inc. 10725 N. De Anza Blvd., Cup ertino, CA 95014-2000 USA 2 I.B.M. Thomas J. Watson Research Center P.O. Box 704, Yorktown Heights, NY 10598 USA 3 Department of Computer Science University of Illinoi s at Urbana-Champaign 1034 W. Spring eld Ave., Urbana, IL 61801 USA Abstract. We prop ose design patterns as a new mechanism for expressing ob ject-oriented design exp erience. Design patterns identify, name, and abstract common themes in ob ject- oriented design. They capture the intent b ehind a design by identifying ob jects, their col- lab orations, and the distributio n of resp onsibil i ties. Design patterns play many roles in the ob ject-oriented development pro cess: they provide a common vo cabulary for design, they re- duce system complexityby naming and de ning abstractions, they constitute a base of ex- p erience for buildin g reusable software, and they act as building blo cks from which more complex designs can b e built. Design patterns can b e considered reusable micro-architectures that contribute to an overall system architecture. We describ e how to express and organize design patterns and intro duce a catalog of design patterns. We also describ e our exp erience in applying design patterns to the design of ob ject-oriented systems. 1 Intro duction Design metho ds are supp osed to promote go o d design, to teach new designers how to design well, and to standardize the way designs are develop ed. Typically, a design metho d comprises a set of syntactic notations usually graphical and a set of rules that govern how and when to use each notation. It will also describ e problems that o ccur in a design, how to x them, and howtoevaluate a design. Studies of exp ert programmers for conventional languages, however, have shown that knowledge is not organized simply around syntax, but in larger conceptual structures such as algorithms, data structures and idioms [1, 7, 9, 27], and plans that indicate steps necessary to ful ll a particular goal [26]. It is likely that designers do not think ab out the notation they are using for recording the design. Rather, they lo ok for patterns to match against plans, algorithms, data structures, and idioms they have learned in the past. Go o d designers, it app ears, rely on large amounts of design exp erience, and this exp erience is just as imp ortant as the notations for recording designs and the rules for using those notations. Our exp erience with the design of ob ject-oriented systems and frameworks [15,17,22, 30, 31] b ears out this observation. Wehave found that there exist idiomatic class and ob ject structures that help make designs more exible, reusable, and elegant. For example, the Mo del-View-Controller MVC paradigm from Smalltalk [19] is a design structure that separates representation from pre- sentation. MVC promotes exibility in the choice of views, indep endent of the mo del. Abstract factories [10] hide concrete sub classes from the applications that use them so that class names are not hard-wired into an application. ? Work p erformed while at UBILAB, Union Bank of Switzerland, Zurich, Switzerland. To app ear in ECOOP '93 ConferenceProceedings, Springer-VerlagLecture Notes in Computer Science. Well-de ned design structures like these have a p ositive impact on software development. A software architect who is familiar with a go o d set of design structures can apply them immediately to design problems without having to rediscover them. Design structures also facilitate the reuse of successful architectures|expressing proven techniques as design structures makes them more readily accessible to develop ers of new systems. Design structures can even improve the do cumentation and maintenance of existing systems by furnishing an explicit sp eci cation of class and ob ject interactions and their underlying intent. To this end we prop ose design patterns, a new mechanism for expressing design structures. Design patterns identify, name, and abstract common themes in ob ject-oriented design. They pre- serve design information by capturing the intent b ehind a design. They identify classes, instances, their roles, collab orations, and the distribution of resp onsibilities. Design patterns have many uses in the ob ject-oriented development pro cess: { Design patterns provide a common vo cabulary for designers to communicate, do cument, and explore design alternatives. They reduce system complexityby naming and de ning abstractions that are ab ove classes and instances. A go o d set of design patterns e ectively raises the level at which one programs. { Design patterns constitute a reusable base of exp erience for building reusable software. They distill and provide a means to reuse the design knowledge gained by exp erienced practitioners. Design patterns act as building blo cks for constructing more complex designs; they can b e considered micro-architectures that contribute to overall system architecture. { Design patterns help reduce the learning time for a class library. Once a library consumer has learned the design patterns in one library, he can reuse this exp erience when learning a new class library. Design patterns help a novice p erform more like an exp ert. { Design patterns provide a target for the reorganization or refactoring of class hierarchies [23]. Moreover, by using design patterns early in the lifecycle, one can avert refactoring at later stages of design. The ma jor contributions of this pap er are: a de nition of design patterns, a means to describ e them, a system for their classi cation, and most imp ortantly, a catalog containing patterns wehave discovered while building our own class libraries and patterns wehave collected from the literature. This work has its ro ots in Gamma's thesis [11], which abstracted design patterns from the ET++ framework. Since then the work has b een re ned and extended based on our collective exp erience. Our thinking has also b een in uenced and inspired by discussions within the Architecture Handb o ok Workshops at recent OOPSLA conferences [3, 4]. This pap er has two parts. The rst intro duces design patterns and explains techniques to describ e them. Next we present a classi cation system that characterizes common asp ects of patterns. This classi cation will serve to structure the catalog of patterns presented in the second part of this pap er. We discuss how design patterns impact ob ject-oriented programming and design. We also review related work. The second part of this pap er the App endix describ es our current catalog of design patterns. As we cannot include the complete catalog in this pap er it currently runs over 90 pages [12], we give instead a brief summary and include a few abridged patterns. Each pattern in this catalog is representative of what we judge to b e go o d ob ject-oriented design. Wehave tried to reduce the sub jectivity of this judgmentby including only design patterns that have seen practical application. Every design pattern wehave included works|most have b een used at least twice and have either b een discovered indep endently or have b een used in a variety of application domains. 2 Design Patterns A design pattern consists of three essential parts: 1. An abstract description of a class or ob ject collab oration and its structure. The description is abstract b ecause it concerns abstract design, not a particular design. 2. The issue in system design addressed by the abstract structure. This determines the circum- stances in which the design pattern is applicable. 3. The consequences of applying the abstract structure to a system's architecture. These determine if the pattern should b e applied in view of other design constraints. Design patterns are de ned in terms of ob ject-oriented concepts. They are suciently abstract to avoid sp ecifying implementation details, thereby ensuring wide applicability, but a pattern may provide hints ab out p otential implementation issues. We can think of a design pattern as a micro-architecture. It is an architecture in that it serves as a blueprint that mayhave several realizations. It is \micro" in that it de nes something less than a complete application or library.To b e useful, a design pattern should b e applicable to more than a few problem domains; thus design patterns tend to b e relatively small in size and scop e. A design pattern can also b e considered a transformation of system structure. It de nes the context for the transformation, the change to b e made, and the consequences of this transformation. To help readers understand patterns, eachentry in the catalog also includes detailed descriptions and examples. We use a template Figure 1 to structure our descriptions and to ensure uniformity between entries in the catalog. This template also explains the motivation b ehind its structure. The App endix contains three design patterns that use the template. We urge readers to study the patterns in the App endix as they are referenced in the following text. 3 Categorizing Design Patterns Design patterns vary in their granularity and level of abstraction. They are numerous and have common prop erties. Because there are many design patterns, we need a way to organize them. This section intro duces a classi cation system for design patterns. This classi cation makes it easy to refer to families of related patterns, to learn the patterns in the catalog, and to nd new patterns.