Design Patterns

Their definition, borrowed from the architect Christopher Alexander: a pattern describes a problem that occurs repeatedly, and the core of a solution to it, in a way that the solution can be reused without ever doing it the same way twice.

The emphasis on recurrence is what distinguishes a pattern from a technique. They are documenting solutions that experienced designers had converged on independently, not inventing new ones.

They did not invent these. They noticed experienced designers had independently converged on the same answers.

Devmark’s reading — not a quotation from the book

The book's largest and least disputed effect was linguistic. Before it, one programmer describing a design to another had to explain the whole structure; afterwards, naming the pattern conveyed it.

Observer, Factory, Strategy, Decorator, Adapter and Singleton are now common speech in software teams, and most people using them have never opened the book.

Creational patterns concern how objects are made — Factory Method, Abstract Factory, Builder, Prototype, Singleton. Structural patterns concern how objects are composed — Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.

Behavioural patterns concern how objects communicate and distribute responsibility — Observer, Strategy, Command, Template Method, State, Chain of Responsibility, and others. The grouping is useful for browsing rather than analytically deep.

Two maxims recur throughout and are more valuable than any individual pattern. Programme to an interface, not an implementation. Favour object composition over class inheritance.

The second is the book's most consequential argument and was counter-cultural at the time, when deep inheritance hierarchies were considered the point of object orientation. The intervening decades have substantially vindicated it.

A criticism that has grown stronger with time: several patterns exist to work around limitations of the languages the authors used.

Strategy, Command and Template Method are largely unnecessary in a language with first-class functions; Iterator is built into most modern languages; Singleton is now widely considered an anti-pattern. Peter Norvig's observation that many patterns are invisible or trivial in more expressive languages is the standard form of this critique.

Several patterns are workarounds for missing language features. In a language with first-class functions they vanish.

Devmark’s reading — not a quotation from the book

The book's most damaging legacy was not its content but its adoption. A generation of developers applied patterns as a demonstration of competence rather than in response to a problem.

The authors warn against this explicitly — patterns are solutions to problems you actually have — and the warning was widely ignored, producing codebases with elaborate indirection serving no purpose.

Poorly, by modern standards. The examples are C++ and Smalltalk, the diagrams use a pre-UML notation, and the structure is a reference catalogue rather than a narrative.

Nobody reads it straight through successfully. Its intended use is consultation when you have a specific structural problem, and even then most readers now get the content from secondary sources.

The vocabulary, completely. The composition-over-inheritance principle, strongly. Several individual patterns — Observer, Adapter, Facade, Decorator, Strategy — remain useful descriptions regardless of how they are implemented.

What has not survived is the implied claim that this is the right level of abstraction for thinking about design, and the assumption that object-oriented decomposition is the default.

It is among the most influential software books ever published, and its influence is now largely indirect: the ideas are embedded in frameworks, languages and standard practice rather than being consciously applied.

That is arguably the best outcome a book of this kind can have — the contents became infrastructure.

The two principles are worth more than the catalogue: programme to interfaces, and prefer composition to inheritance. Both remain correct and both are still routinely violated.

And the discipline the book states and its readers ignored — a pattern is an answer to a problem you have, and applying one without the problem adds cost with no benefit.