Design Patterns / Gamma, Helm, Johnson and Vlissides

Tal Cohen's Bookshelf: A Collection of Personal Opinions about Books

Sunday, 13 July 1997

The book is an introduction to the idea of design patterns in software engineering, and a catalog of twenty-three common patterns. The nice thing is, most experienced OOP designers will find out they’ve known about patterns all along. It’s just that they’ve never considered them as such, or tried to centralize the idea behind a given pattern so that it will be easily reusable.

We all know the value of design experience. How many times have you had design deja-vu — that feeling that you’ve solved a problem before but not knowing exactly where or how?

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.

Novelists and playwrights rarely design their plots from scratch. Instead, they follow patterns like “Tragically Flawed Hero” (Macbeth, Hamlet, etc.) or “The Romantic Novel” (countless romance novels). In the same way, object-oriented designers follow patterns like “represent states with objects” and “decorate objects so you can easily add/remove features.” Once you know the pattern, a lot of design decisions follow automatically.

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.

Find this book

Also Reviewed:

Pattern Hatching: Design Patterns Applied by John Vlissides; a great read if you’re interested in inventing or documenting design patterns of your own.

New Reviews Notification

To receive notifications as new reviews are published, consider following the RSS feed.

[Post a comment on this review]

[Permalink to this review] [Fold all comments] [Unfold all comments]

		Tal Cohen writes: 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: The factories mechanism (not to be confused with factory methods) includes both supplier-side factories and client-side factories. The former makes the Factory Method, Singleton, and Flyweight patterns redundant, and the latter makes the Abstract Factory pattern redundant. (They also obliviate the need for the well-known Object Pool pattern, although this pattern is not presented in the original Gang of Four book.) The shakeins mechanism can replace, or present a better implementation mechanism for, the Chain of Responsibility pattern. Shakeins can also simplify, or present a better alternative for, the Observer pattern. Finally, the Object Evolution mechanism completely obliterates any need for the State pattern. Combined with Shakeins, the third form of Object Evolution, known as S-Evolution, can also replace the Decorator pattern. Complete details about each of these mechanisms can be found in the links above, or in the dissertation itself. The relation between the mechanisms and the classic design patterns is discussed in the summary chapter of the dissertation.
		[117] Posted on Saturday, 05 May 2007 at 15:40 GMT [Reply to this] [Permalink]

[Post a comment on this review] [Back to Main Page]