Comments on Design Patterns

Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, distills a number of useful tools for crafting designs. However, not all of these patterns are created equal. Here's my summary, in subjective order:
Parts and wholes conform to the same interface.
An intermediary which changes the interface of an object.
Stylized kind of adapter.
An intermediary which attaches behavior to, but does not change the interface of, an object.
Stub which bridges to another machine or device. Aka "virtual object."
Delegation for changing behavior. Generalizes higher-order functions.
A stylized kind of Strategy pattern.
Encapsulate state-dependent behavior into separate objects. Switch-style forwarding.
Template method
A framework. "Don't call us, we'll call you." Combination of facade and strategy.
Stylizes the use of other classes, without adding functionality. Aka "convenience routines."
Reduces the number of interconnections between senders and candidate recievers. Can do other things besides forward messages.
Chain of responsibility
Mediator which only forwards messages. Aka "merge."
Maintain a list of dependents to notify of changes. Part of MVC.
Omit state from an object's representation, to promote sharing. State is not stored but rather passed as a method argument.
Opaque object for holding state. Can be used for iteration.
Stylized kind of visitor. Distributes an operation over a hierarchy of composite patterns.
It is interesting to note that several other organizations of these patterns have been proposed, by various people, all of which seem to associate different things with each pattern. It is still an open question what organization designing minds use.


The book does a great job of pointing out pitfalls in C++, e.g. In fact, some of the patterns appear to exist simply because of C++'s limitations:
Abstract factory
A class parameterized by another class, sort of. An artifact of classes not being values in C++.
Factory method
A method parameterized by another class, sort of. Same explanation.
Aka "oddball." An artifact of the object/class distinction in C++.
Structured instantiation. Could use a closure instead, but C++ doesn't support them.
A callback object. Can return a command which undoes this one. Could replace with a closure, if only one Exec() method is needed.
Add new operations to classes without changing them. An artifact of multi-methods being missing from C++.


SICP has far more patterns and more complex patterns, but doesn't distill and analyze them the way Design Patterns does.

The Beta language manual is also a good source of patterns.

Thomas Minka
Last modified: Mon Jan 6 14:08:16 EST 1997