Design Patterns : Elements of Reusable Object-Oriented Software

Design Patterns: Elements of Reusable Object-Oriented Software 
393 
Another important change over the past year has been a greater emphasis onthe 
problem that a pattern solves. It's easiest to see a pattern as asolution, as 
a technique that can be adapted and reused. It's harderto see when it is 
appropriate
—
to characterize the problems itsolves and the context in which it's 
the best solution. In general,it's easier to see 
what
someone is doing than to 
know 
why
,and the "why" for a pattern is the problem it solves. Knowingthe purpose 
of a pattern is important too, because it helps us choosepatterns to apply. It 
also helps us understand the design of existingsystems. A pattern author must 
determine and characterize the problemthat the pattern solves, even if you have 
to do it after you'vediscovered its solution. 
The Pattern Community 
We aren't the only ones interested in writing books that catalog thepatterns 
experts use. We are a part of a larger community interestedin patterns in general 
and software-related patterns in particular.Christopher Alexander is the 
architect who first studied patterns inbuildings and communities and developed 
a "pattern language" forgenerating them. His work has inspired us time and again. 
So it'sfitting and worthwhile to compare our work to his. Then we'll look atothers' 
work in software-related patterns. 
Alexander's Pattern Languages 
There are many ways in which our work is like Alexander's. Both arebased on observing 
existing systems and looking for patterns in them.Both have templates for 
describing patterns (although our templates arequite different). Both rely on 
natural language and lots of examplesto describe patterns rather than formal 
languages, and both giverationales for each pattern. 
But there are just as many ways in which our works are different: 
1.
People have been making buildings for thousands of years, and thereare many 
classic examples to draw upon. We have been making softwaresystems for a 
relatively short time, and few are considered classics. 
2.
Alexander gives an order in which his patterns should be used; we havenot. 
3.
Alexander's patterns emphasize the problems they address, whereasdesign 
patterns describe the solutions in more detail. 
4.
Alexander claims his patterns will generate complete buildings. We donot 
claim that our patterns will generate complete programs. 
When Alexander claims you can design a house simply by applying hispatterns one 
after another, he has goals similar to those ofobject-oriented design 
methodologists who give step-by-step rules fordesign. Alexander doesn't deny the 

---