Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers of new systems. Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. 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 a designer get a design "right" faster.
None of the design patterns in this book describes new or unproven designs. We have included only designs that have been applied more than once in different systems. Most of these designs have never been documented before. They are either part of the folklore of the object-oriented community or are elements of some successful object-oriented systems—neither of which is easy for novice designers to learn from. So although these designs aren't new, we capture them in a new and accessible way: as a catalog of design patterns having a consistent format.
Despite the book's size, the design patterns in it capture only a fraction of what an expert might know. It doesn't have any patterns dealing with concurrency or distributed programming or real-time programming.It doesn't have any application domain-specific patterns. It doesn't tell you how to build user interfaces,how to write device drivers,or how to use an object-oriented database. Each of these areas has its own patterns,and it would be worthwhile for someone to catalog those too.
What is a Design Pattern?
Christopher Alexander says,"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 can use this solution a million times over, without ever doing it the same way twice". Even though Alexander was talking about patterns in buildings and towns,what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors,but at the core of both kinds of patterns is a solution to a problem in a context.
In general,a pattern has four essential elements:
1. The pattern name is a handle we can use to describe a design problem,its solutions,and consequences in a word or two.Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction. Having a vocabulary for patterns lets us talk about them with our colleagues,in our documentation,and even to ourselves. It makes it easier to think about designs and to communicate them and their trade-offs to others. Finding good names has been one of the hardest parts of developing our catalog.
2. The problem describes when to apply the pattern. It explains the problem and its context. It might describe specific design problems such as how to represent algorithms as objects. It might describe class or object structures that are symptomatic of an inflexible design. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.