|Design Patterns / Gamma, Helm, Johnson and Vlissides|
|Reviewed by Tal Cohen||Sunday, 13 July 1997|
The concept of design patterns was first discussed by Christopher Alexander, an architect, back in 1977. If someone from the software industry would have considered Alexander’s’ words back then, perhaps the first book about design patterns in software would have dealt with patterns in FORTRAN programs. As it happens, software design patterns were first discussed in this era, when most software design is object-oriented in nature.
The most noticeable concept of patterns is reusability. Code reusability is an important issue with huge financial implications, but many believe it never worked properly, and maybe it never will. Design Patterns could change all this, because we’re talking about reusable designs here, as opposed to code reuse. And while code reuse is a good and important thing, design reuse is probably much more effective when done correctly. The designs in the book are all solid, tested designs from real-life projects, and examples of uses in known programs and libraries are always given. Further, for each design, the authors include a detailed list of benefits side-by-side with possible downsides.
The book is extremely useful, even if only few of the presented patterns are new to you. The patterns in the catalog are presented in such a way that incorporating them into projects (at the design stage) will be as smooth as possible. The fact these “design building blocks” are so clearly arranged will help make almost any project design clearer. Still, I expect that over the years many of these patterns (and in particular, creational patterns) will disappear from pattern catalogues as they become an integrated part of programming languages.
As the first book to include a catalog of patterns, Design Patterns had set a standard of, or maybe I should say a pattern for, presenting patterns. Most other pattern catalogs that were published later follow these clear guidelines. This is an important issue, and one could only wish that there was such a standard, widely-accepted method for presenting algorithms and other aspects of software engineering.
Patterns as problem indicators
The review above was written and published ten years ago. Since then, I have learned (and was not the first to learn) that many patterns are nothing more than indicators of problems in the programming language itself.
My own Ph.D. dissertation, which technically deals with aspect-oriented software development, presents several suggestions for design improvements in programming languages. These improvements (some minor and easy to incorporate, some more far-reaching) directly affect eight of the original 23 patterns, either rendering them superfluous or improving their usability and extent:
| Posted on Saturday, 05 May 2007 at 15:40 GMT [Reply to this] [Permalink]|