Design Patterns : Elements of Reusable Object-Oriented Software

Design Patterns: Elements of Reusable Object-Oriented Software 
394 
need for creativity; some of hispatterns require understanding the living habits 
of the people whowill use the building, and his belief in the "poetry" of 
designimplies a level of expertise beyond the pattern languageitself.
1
But his 
description of how patternsgenerate designs implies that a pattern language can 
make the designprocess deterministic and repeatable. 
The Alexandrian point of view has helped us focus on designtrade-offs
—
the different 
"forces" that help shape a design. Hisinfluence made us work harder to understand 
the applicability andconsequences of our patterns. It also kept us from worrying 
aboutdefining a formal representation of patterns. Although such arepresentation 
might make automating patterns possible, at this stageit's more important to 
explore the space of design patterns than toformalize it. 
From Alexander's point of view, the patterns in this book do not forma pattern 
language. Given the variety of software systems that peoplebuild, it's hard to 
see how we could provide a "complete" set ofpatterns, one that offers step-by-step 
instructions for designing anapplication. We can do that for certain classes of 
applications, suchas report-writing or making a forms-entry system. But our 
catalog isjust a collection of related patterns; we can't pretend it's a 
patternlanguage. 
In fact, we think it's unlikely that there will 
ever
be acomplete pattern language 
for software. But it's certainly possibleto make one that is 
more
complete. 
Additions would have toinclude frameworks and how to use them [Joh92], patterns 
foruser interface design [BJ94], analysispatterns [Coa92], and all the other 
aspects of developingsoftware. Design patterns are just a part of a larger 
patternlanguage for software.