A Look Back: Why We Wrote Design Patterns: Elements of Reusable Object-Oriented Software
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Designing object-oriented software is hard—designing reusable object-oriented software is even harder. Experienced object-oriented designers will tell you that a reusable and flexible design is difficult, if not impossible, to get "right" the first time, and that multiple attempts at reuse with subsequent redesigns are normal.
Yet experience has shown that many object-oriented systems exhibit idiomatic and recurring patterns and structures—objects that solve particular design problems and make designs more flexible, elegant, and ultimately reusable. The Model-View-Controller (MVC) idiom found in Smalltalk is a design that separates representation defined by a Model from possible screen presentations defined by Views. Model-View-Controller is applied widely throughout Smalltalk systems.
These recurring design structures or patterns of design have a positive impact on object-oriented design and development. They help designers reuse successful designs and architectures based on prior experiences. A designer who is familiar with a set of design patterns can apply them immediately to design problems without having to rediscover the design solutions. This design experience is somewhat similar to that of architects or engineers who design buildings. Just as they may follow certain standard designs for buildings (skyscrapers with a solid core and hanging glass wall, energy efficient solar house) or bridges (suspension, cantilever, truss), so do object-oriented designers follow patterns like "represent states with objects" and "use wrappers to flexibly add/remove features from objects." Once you have the pattern, many design decisions follow.
This design experience is valuable. What is often missing, especially in software, is a record of this experience for others to use. How many times have you had that feeling, "I have solved this problem before in a previous design"? Of course, we all have had cases of design "deja-vu." If only we knew about the existing experience, the design issues, and the previously discovered solutions beforehand!
Our main goal in writing Design Patterns was recording the experience of designing reusable object-oriented software. We set out to systematically name, explain, evaluate, and catalog the commonly occurring important design patterns found in object-oriented systems. We try to capture in one place the wealth of experience about the design of reusable object-oriented software in a form that provides a ready reference for designers of object-oriented systems.
Central to Design Patterns is the catalog of 23 design patterns. The patterns described fall into three broad categories: creational patterns that concern the instantiation of objects, structural patterns that concern how objects and classes stand in relationship to each other, and behavioral patterns that concern the distribution of behavior and responsibilities across classes and objects.
Each description of a design pattern names, abstracts, and identifies the key aspects of a common and recurring design structure that can be used to create a reusable object-oriented design. The design pattern identifies the participating classes, including their instances, responsibilities, and collaborations. Each pattern concerns one particular design problem or issue. It describes the circumstances in which the design pattern is applicable, whether the pattern can be applied in view of other design constraints, and the consequences and tradeoffs of using the pattern in a larger design. As we must eventually use our designs, the description also includes how the design pattern may be implemented using simple object-oriented concepts in object-oriented programming languages like C++ or Smalltalk.
Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design structures makes them more readily accessible to developers of new systems. The experience embodied in design patterns helps a designer evaluate which design alternatives will make a system reusable and which alternatives will compromise future extensibility. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent. Put simply, design patterns help designers get their designs "right" the first time.
Few of the design patterns you will find in Design Patterns describe our designs. We consciously avoided describing design tricks or techniques that we have invented. Rather, we tried to only include designs that have been applied in practice to implemented and working systems. However, most of these designs have never been documented before. They are either known only as part of the object-oriented folklore, or learned only from intimate knowledge of the design of some successful object-oriented systems—neither of which are particularly useful or available references. So, although the designs described here are not new, they are presented in a new and accessible way—as a catalog of design patterns following a standard template.