Design Patterns : Elements of Reusable Object-Oriented Software

Design Patterns: Elements of Reusable Object-Oriented Software 
387 
Decorator (196) to override these properties on partsof the composition. It could 
use the Observer pattern to tie oneobject structure to another and the State pattern 
to let a componentchange its behavior as its state changes. The composition itself 
mightbe created using the approach in Builder (110), and itmight be treated as 
a Prototype (133) by some otherpart of the system. 
Well-designed object-oriented systems are just like this
—
they havemultiple 
patterns embedded in them
—
but not because their designersnecessarily thought in 
these terms. Composition at the 
pattern
level rather than the class or object levels 
lets us achieve the samesynergy with greater ease. 
12
This theme runs through other kinds of patterns, too. Abstract Factory (99), 
Builder (110), and Prototype (133) all encapsulate knowledge about howobjects 
are created. Decorator (196) encapsulates responsibility that can be added to 
an object. Bridge (171) separates an abstraction from its implementation, letting 
them vary independently. 

---

Design Patterns: Elements of Reusable Object-Oriented Software 
388 
6.
 
Conclusion 
It's possible to argue that this book hasn't accomplished much. Afterall, it 
doesn't present any algorithms or programming techniques thathaven't been used 
before. It doesn't give a rigorous method fordesigning systems, nor does it develop 
a new theory of design
—
itjust documents existing designs. You could conclude that 
itmakes a reasonable tutorial, perhaps, but it certainly can't offermuch to an 
experienced object-oriented designer. 
We hope you think differently. Cataloging design patterns isimportant. It gives 
us standard names and definitions for thetechniques we use. If we don't study 
design patterns in software, wewon't be able to improve them, and it'll be harder 
to come up with newones. 
This book is only a start. It contains some of the most common designpatterns 
that expert object-oriented designers use, and yet peoplehear and learn about 
them solely by word of mouth or by studyingexisting systems. Early drafts of the 
book prompted other people towrite down the design patterns they use, and it should 
prompt evenmore in its current form. We hope this will mark the start of amovement 
to document the expertise of software practitioners. 
This chapter discusses the impact we think design patterns willhave, how they 
are related to other work in design, and how you canget involved in finding and 
cataloging patterns.