History of Patterns

Origins in building architecture

The idea of a pattern language predates software. In the 1970s, the architect Christopher Alexander and his colleagues published A Pattern Language and The Timeless Way of Building. They described recurring problems in towns and buildings, such as where to put windows in a room people sit in, and named a solution for each.

Each of Alexander's patterns had the same parts: a context, a problem shaped by competing forces, and a solution that resolves those forces. The patterns linked to each other, so small ones refined larger ones. That structure, more than any single pattern, is what software borrowed.

Arrival in software

In the late 1980s, Kent Beck and Ward Cunningham experimented with applying Alexander's ideas to user interface design in Smalltalk. Others in the object-oriented community picked up the idea through workshops and conferences such as OOPSLA.

The turning point came in 1994 with Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. The four authors became known as the Gang of Four (GoF). Their book catalogued 23 patterns with examples in C++ and Smalltalk and grouped them by purpose into creational, structural and behavioral.

This site covers 22 of those patterns. The 23rd, Interpreter, is rarely used outside language tooling and is left out of the catalog.

Timeline

Period	Milestone
1977–1979	Alexander publishes A Pattern Language and The Timeless Way of Building
1987	Beck and Cunningham present early software pattern work
1994	The GoF book is published; the first Pattern Languages of Programs (PLoP) conference runs
1996–2003	Pattern books spread into architecture, enterprise integration and concurrency
1999	Martin Fowler's Refactoring links code smells to step-by-step fixes
2000s	Mainstream languages add generics, lambdas and closures
2010s onward	Functional styles and language features absorb several patterns into idioms

Patterns and refactoring meet

Early on, patterns were often treated as up-front design tools: pick the patterns, then write the code. Refactoring changed that. Fowler's book, and later work by Joshua Kerievsky on refactoring toward patterns, made the case that you should arrive at a pattern by improving working code, one tested step at a time.

That is the approach this site takes. Each code smell points to techniques, and some techniques end in a pattern. For example, Replace Type Code with State/Strategy lands you at State or Strategy. See What is refactoring.

How the languages changed the patterns

The GoF examples were written for C++ and Smalltalk in the early 1990s. Several patterns compensated for features those languages lacked or made awkward:

• First-class functions make many uses of Strategy and Command a function parameter.
• Built-in iteration protocols (for...of, Python iterators, Java Iterable) make hand-rolled Iterator classes rare.
• Modules and dependency injection replaced many uses of Singleton.
• Pattern matching and sealed types cover cases that once needed Visitor. See Visitor and double dispatch.
• Event emitters and reactive streams in standard libraries implement Observer for you.

The problems did not go away. The solution moved into the language or the standard library. Knowing the pattern still helps you recognize what the built-in feature is doing and when it is not enough.

What lasted

Three ideas from this history still pay off:

1. Names. A shared vocabulary lets two developers, or a developer and an agent, agree on a design in one sentence.
2. Forces. Alexander's insistence on stating the tensions is what lets you decide when a pattern does not fit.
3. Composition over inheritance. The GoF book argued for it in 1994, and most modern code has taken the advice.

For the arguments against patterns that grew alongside their popularity, see Criticism of patterns.