What a Design Pattern Is: A Named Solution to a Recurring Problem

A shape of classes with a name you can say aloud, written fresh in your own code each time.

A design pattern is a general, reusable solution to a problem that keeps appearing in object-oriented design, written down with a name so that developers can discuss it. It describes which classes to create, what each one is responsible for, and how they talk to each other, and you write that in your own language for your own problem, so there is nothing to install or copy. This card explains what every pattern description contains, and why the name matters as much as the solution.

The idea comes from architecture. In 1977 Christopher Alexander and his colleagues published "A Pattern Language", a catalogue of solutions to problems that recur in towns and buildings. One of them, "window place", says that people are drawn to windows, so a room that wants to be lived in needs a place to sit by one. It describes no particular window. It names a problem and the shape of a solution, and leaves the design to the builder.

In 1994 Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides applied the same idea to software in "Design Patterns: Elements of Reusable Object-Oriented Software". The four authors are known as the Gang of Four, and their 23 patterns are the classic catalogue this subject teaches. They describe every pattern with four essential elements.

The four elements, filled in for the Iterator pattern

Name: Iterator; A word that lets two developers mean the same design.
Problem: Code needs to visit every element of a collection without depending on how the collection stores them.; When the pattern applies.
Solution: A separate iterator object keeps the position and hands out one element at a time.; The classes and their responsibilities, not finished code.
Consequences: The collection can change its storage freely, at the cost of one more object per traversal.; What you gain and what it costs.

The name is what makes a pattern useful in a conversation. "Wrap it in an adapter" tells a colleague the whole design in four words. The problem says when to apply the pattern, and just as usefully, when not to. The solution is a shape, so the same pattern looks different in Python and in Java. The consequences are the trade-off, and every pattern has one: each adds at least one class or one level of indirection, which is worth it only when the problem is real.

Alexander's analogy breaks in one place. A window place is built once and stays for the life of the building. A software pattern is refactored in when a problem appears and refactored out again when it goes, so a pattern in code is a decision you keep revisiting.

What changes for you is that a pattern becomes something to recognise rather than something to memorise. Reading an unfamiliar codebase, you will start to see an iterator, a factory or an observer, and know at once what each class is for and which changes the design expects.

← → move through sections and cards