Author: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides · Published: 1994 · Genre: Programming, Software Design
The biggest strength of Design Patterns is the vocabulary it gave programmers: 23 named solutions, such as Observer, Strategy and Adapter, that let a team describe a design in a word. Its biggest weakness is how it reads and how it has been used: a dry, academic catalogue written for early-1990s C++ and Smalltalk that encouraged a generation to force patterns into code that didn’t need them. Experienced object-oriented developers will still learn from it; beginners should start with a friendlier book.
The core ideas
The four authors, nicknamed the Gang of Four, borrowed the idea of a pattern language from the architect Christopher Alexander and applied it to object-oriented software.
- Two principles. The introduction argues that you should program to an interface, not an implementation, and favor object composition over class inheritance. These two lines are arguably worth more than any single pattern.
- Three families of patterns. Creational patterns deal with how objects are made: Abstract Factory, Builder, Factory Method, Prototype and Singleton. Structural patterns deal with how they are combined: Adapter, Bridge, Composite, Decorator, Facade, Flyweight and Proxy. Behavioral patterns deal with how objects communicate and share responsibility: Observer, Strategy, Command, Iterator, State, Visitor and five others.
- A fixed template. Every pattern is described the same way: intent, motivation, applicability, structure, participants, collaborations, consequences, implementation, sample code, known uses and related patterns.
- A case study. An early chapter designs Lexi, a WYSIWYG document editor, showing how patterns such as Composite, Strategy and Decorator combine in one system.
What’s great
- Naming things. Saying “make it an Observer” or “wrap it in a Decorator” conveys a whole design in a phrase. Many of these patterns are now built into languages and libraries: iterators, event listeners, and Java’s stream classes, which wrap one another decorator-style.
- Honest trade-offs. The consequences sections spell out the costs as well as the benefits. Decorator, for instance, gives flexibility but produces lots of small look-alike objects that can be hard to learn and debug.
- Composition over inheritance. This advice has aged better than anything else in the book. Newer languages such as Go and Rust leave out class inheritance entirely.
What’s weak
Many patterns are workarounds for the limits of C++ and similar statically typed languages. In a 1996 presentation, Peter Norvig argued that 16 of the 23 patterns become invisible or simpler in dynamic languages such as Lisp and Dylan. Paul Graham went further, calling patterns in code a sign that your abstractions aren’t powerful enough. With first-class functions, Strategy and Command are often just a function you pass around, and Iterator is a language feature.
Then there is overuse. The book’s influence produced a wave of pattern-heavy code full of factories, managers and layers of indirection built for flexibility nobody needed. Singleton in particular is now widely treated as an anti-pattern, since it is global state in disguise and makes testing harder.
Finally, the prose is dense and the sample code dated. Few people read it cover to cover, and the structure diagrams use a pre-UML notation that looks unfamiliar today.
Who should read it
Developers with a few years of object-oriented experience in Java, C#, C++ or similar languages. Read the first two chapters in full, then look up individual patterns as you meet them. If you’re new to the subject, start with Head First Design Patterns, and come back to the original for the precision.
Rating: 3.5/5
Image credits — Featured image: cover image via Open Library; cover design © the publisher, shown for review purposes. In-article images: Photo by Kaleidico on Unsplash.
