|
It is perhaps easiest to think of a design pattern as a template for a solution. When presented with a
problem, the first thing we do is identify the defining characteristics of the problem. Then, we examine
our armoury to see whether we have a generic solution that solves the problem we've characterized. If
so, we apply the solution template and hence solve the problem.
The design pattern itself describes both the defining characteristics of the problem and the
characteristics of the solution. The solution template is tried and tested, which means that once we've
correctly identified which pattern to use, we can apply it without the need to do research and proof-ofconcept
testing.
This process is one that applies in all walks of life - architecture, medicine, furniture restoration ... Not
all disciplines use the term "design pattern", but in any case the process is the same. This book is about
design patterns in object-oriented programming (OOP).
So, a design pattern in OOP is a solution template - it describes the characteristics of the problem and of
the solution, but leaves you {the developer} to implement the details of the solution. Design patterns are
not about programming "tricks"; rather, they penetrate to the heart of the problem at hand, and allow
you to break things down into constituent parts. Design patterns help you see the path toward the
overall solution, without dictating it.
This book draws on the work of the Gang of Four {or GoF} - Erich Gamma, Richard Helm,
RalphJohnson, and John Vlissides - whose seminal book Design Patterns: Elements o/Reusable ObjectOriented
Software {Addison-Wesley, ISBN 0-201-63361-2} describes the fundamentals of design patterns
in OOP and catalogs 23 design patterns in significant detail. |
