Designing object-oriented software is hard, and designing reusable object-oriented software is evenharder. You must find pertinent objects, factor them into classes at the right granularity, define classinterfaces and inheritance hierarchies, and establish key relationships among them. Your design should bespecific to the problem at hand but also general enough to address future problems and requirements.You also want to avoid redesign, or at least minimize it. Experienced object-oriented designers will tellyou that a reusable and flexible design is difficult if not impossible to get "right" the first time. Before adesign is finished, they usually try to reuse it several times, modifying it each time.Yet experienced object-oriented designers do make good designs. Meanwhile new designers areoverwhelmed by the options available and tend to fall back on non-object-oriented techniques they'veused before. It takes a long time for novices to learn what good object-oriented design is all about.Experienced designers evidently know something inexperienced ones don't. What is it?One thing expert designers know not to do is solve every problem from first principles. Rather, they reusesolutions that have worked for them in the past. When they find a good solution, they use it again andagain. Such experience is part of what makes them experts. Consequently, you'll find recurring patterns ofclasses and communicating objects in many object-oriented systems. These patterns solve specific designproblems and make object-oriented designs more flexible, elegant, and ultimately reusable. They helpdesigners reuse successful designs by basing new designs on prior experience. A designer who is familiarwith such patterns can apply them immediately to design problems without having to rediscover them.An analogy will help illustrate the point. Novelists and playwrights rarely design their plots from scratch.Instead, they follow patterns like "Tragically Flawed Hero" (Macbeth, Hamlet, etc.) or "The RomanticNovel" (countless romance novels). In the same way, object-oriented designers follow patterns like"represent states with objects" and "decorate objects so you can easily add/remove features." Once youknow the pattern, a lot of design decisions follow automatically.We all know the value of design experience. How many times have you had design déjà-vu—that feelingthat you've solved a problem before but not knowing exactly where or how? If you could remember thedetails of the previous problem and how you solved it, then you could reuse the experience instead ofrediscovering it. However, we don't do a good job of recording experience in software design for othersto use.The purpose of this book is to record experience in designing object-oriented software as design patterns.Each design pattern systematically names, explains, and evaluates an important and recurring design inobject-oriented systems. Our goal is to capture design experience in a form that people can useeffectively. To this end we have documented some of the most important design patterns and presentthem as a catalog.Design patterns make it easier to reuse successful designs and architectures. Expressing proventechniques as design patterns makes them more accessible to developers of new systems. Design patternshelp you choose design alternatives that make a system reusable and avoid alternatives that compromisereusability. Design patterns can even improve the documentation and maintenance of existing systems byfurnishing 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 onlydesigns that have been applied more than once in different systems. Most of these designs have neverbeen documented before. They are either part of the folklore of the object-oriented community or are1 of 27 9/27/2001 5:34 PMIntroduction file:///D|/hires/chap1.htmelements of some successful object-oriented systems—neither of which is easy for novice designers tolearn from. So although these designs aren't new, we capture them in a new and accessible way: as acatalog 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. Itdoesn't have any patterns dealing with concurrency or distributed programming or real-timeprogramming. It doesn't have any application domain-specific patterns. It doesn't tell you how to builduser interfaces, how to write device drivers, or how to use an object-oriented database. Each of theseareas 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 ourenvironment, and then describes the core of the solution to that problem, in such a way that you can usethis solution a million times over, without ever doing it the same way twice" [AIS+77, page x]. Eventhough Alexander was talking about patterns in buildings and towns, what he says is true aboutobject-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead ofwalls 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, andconsequences in a word or two. Naming a pattern immediately increases our design vocabulary. Itlets us design at a higher level of abstraction. Having a vocabulary for patterns lets us talk aboutthem with our colleagues, in our documentation, and even to ourselves. It makes it easier to thinkabout designs and to communicate them and their trade-offs to others. Finding good names hasbeen 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 mightdescribe specific design problems such as how to represent algorithms as objects. It might describeclass or object structures that are symptomatic of an inflexible design. Sometimes the problem willinclude a list of conditions that must be met before it makes sense to apply the pattern. 3. The solution describes the elements that make up the design, their relationships, responsibilities,and