Introduction to Design Patterns — Named Solutions to Recurring Problems

Every experienced developer has solved the same design problem more than once: "this class needs to be told when that one changes", "I need one of several algorithms, chosen at run time", "this object takes twelve optional settings". The second time, you remember roughly what worked. The tenth time, you have a name for it.

A design pattern is that name, together with a description of the problem it solves, the shape of the solution, and the consequences of using it. Patterns let a team say "use an Observer here" instead of describing callbacks for five minutes, and let a reader recognise a familiar structure in unfamiliar code. This chapter covers the 23 classic patterns, and this lesson explains what they are, where they came from, how they are grouped, and when to leave them out.

This builds on SOLID Principles: most patterns are those principles applied to a specific, recurring situation. Every output below was produced by running the code on Java 21 and Python 3.11.

You'll be able to: say what a design pattern is, and name its four essential elements; recognise patterns that the Java and Python standard libraries already use; place a pattern in the right category from the problem it solves; decide when a pattern adds more complexity than it removes.

Table of contents

1. What a design pattern is
2. Where design patterns came from
3. The three categories of design patterns
4. When not to use a pattern
5. Mental-model summary
6. Gotcha checklist
7. Check yourself
8. Sources

1. What a design pattern is

Put simply, design patterns save you from reinventing the wheel each time a familiar design problem comes back.

You already use patterns every day, because the standard libraries are built from them. Sorting with a comparator is the Strategy pattern: the sort algorithm stays fixed, and you pass in the part that varies. A for loop over a collection is the Iterator pattern: you walk the elements without knowing how the collection stores them.

Output:

by length:   [fig, pear, kiwi, banana]
reverse a-z: [pear, kiwi, fig, banana]
initials:    pkfb

Analysis. The same sort call produced two different orders, because the rule it used was a separate object (a Comparator in Java, a key function or reverse flag in Python) passed in from outside. The loop at the end used only hasNext() and next() (Python: iter(), next() and StopIteration), and would work unchanged on a set, a linked list or a file. In Python the strategy is just a function: in a language with first-class functions, several patterns shrink to a language feature. Peter Norvig made this point in 1996, finding that 16 of the 23 patterns are simpler, or invisible, in dynamic languages [3].

Intuition. Mechanism. Each pattern isolates one thing that varies, behind a stable interface. Strategy isolates the algorithm; Iterator isolates how a collection is traversed. Code on the other side of that interface doesn't change when the varying part does.

Concrete bite. Consequences are part of every pattern, and Iterator's include what happens when the collection changes during a traversal. Here both programs remove even numbers from a list while looping over it:

Output (Java):

Java stopped: ConcurrentModificationException
list now: [4, 6, 7]
removeIf: [7]

Output (Python):

Python carried on
list now: [4, 7]
filtered: [7]

Java's ArrayList iterator is fail-fast: it noticed the list had changed under it and threw on the next step [4]. Python's list iterator just moves its index forward, so removing the 2 shifted the 4 into the slot it had already visited, and the 4 was never checked. Python's documentation warns about exactly this [5]. Both behaviours are consequences of how each library implemented the Iterator pattern, and neither is visible from the pattern's shape alone.

2. Where design patterns came from

The idea of a pattern language came from architecture. In A Pattern Language (1977), Christopher Alexander and his colleagues described recurring problems in towns and buildings, and the core of a solution to each. The Gang of Four quote his description: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" [2].

Design patterns for software were formalised by the Gang of Four (GoF), Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, in their 1994 book Design Patterns: Elements of Reusable Object-Oriented Software [1]. They catalogued 23 patterns that kept appearing in well-designed object-oriented software, and grouped them into three categories. The book's first chapter also gives two principles that run through almost every pattern in it: "Program to an interface, not an implementation", and "Favor object composition over class inheritance" [1].

The catalogue was written for C++ and Smalltalk in 1994. Some patterns have since been absorbed into languages: Java's enhanced for loop is the Iterator pattern built into the syntax, and Python's functions make a one-method Strategy class unnecessary. The problems the patterns solve haven't gone away, which is why the names are still the shared vocabulary of design discussions and interviews.

3. The three categories of design patterns

Creational patterns are about how objects are created. They abstract the act of instantiation, so that the rest of the system doesn't depend on which concrete classes are created, or how.

That is the idea behind the factory patterns: the creation logic is hidden from the caller, so it can change without the caller changing. The creational patterns are Singleton, Factory Method, Abstract Factory, Builder and Prototype, covered in Creational Design Patterns.

Structural patterns are about how classes and objects are combined into larger structures, while keeping those structures flexible and efficient. Several of them let objects work together that otherwise couldn't, for example because their interfaces don't match.

That adapter is the Adapter pattern: it lets incompatible components work together without changing either of them. The structural patterns are Adapter, Bridge, Composite, Decorator, Facade, Flyweight and Proxy, covered in Structural Design Patterns.

Behavioural patterns are about how objects interact and divide responsibilities among themselves, while staying loosely coupled.

That is the Mediator pattern: one object controls the communication between others, so they don't need to know about each other. The behavioural patterns are Observer, Strategy, Interpreter, Command, Chain of Responsibility, Mediator, State, Template Method, Visitor, Iterator and Memento. Ten of them are covered in four lessons: Strategy, Template Method and State; Command, Chain of Responsibility and Memento; Observer and Mediator; and Iterator and Visitor. Interpreter, which builds a small language as a class hierarchy, is rarely needed outside parsers and is not covered.

Here is one small, real example from each category:

Output:

creational:  orange juice, from concentrate
structural:  power through micro-USB, adapted to USB-C
behavioural: email service saw 'order 42 placed'
behavioural: stock service saw 'order 42 placed'

Analysis. The caller of VendingMachine.make never names OrangeJuice; the code that uses a UsbC socket never learns that a micro-USB cable is behind it; and OrderEvents doesn't know which services are listening. Each example hides a different thing: which class gets created, how two objects are wired together, and who reacts to what. Those three questions are the three categories.

Intuition. Mechanism. The category tells you which kind of change a pattern absorbs. Creational patterns absorb changes to which concrete classes are created. Structural patterns absorb changes to how objects are assembled. Behavioural patterns absorb changes to which object does what, and when.

Concrete bite. Add an "apple" drink to the program above. Only VendingMachine.make changes, and the code that serves drinks is untouched. Add a third listener, say an analytics service, and only the line that subscribes it is new: OrderEvents.publish doesn't change. If you can't say which of the three kinds of change you expect, you can't pick the right pattern, and any pattern you add is a guess.

4. When not to use a pattern

Every pattern adds structure: extra interfaces, classes and indirection. That structure pays for itself only when the change it isolates actually happens. A few signs that a pattern is costing more than it saves:

• It has one implementation, and no second one in sight. A ShapeFactory that only ever makes circles, or a Strategy interface with a single strategy, is indirection with no benefit. YAGNI applies to patterns too.
• The language already does it. In Python, a function is usually a better Strategy than a one-method class, a module is usually a better Singleton than a class with a private constructor, and keyword arguments usually make a Builder unnecessary.
• Nobody can explain which change it absorbs. A pattern added because it "might be useful later" is a guess, and it makes the code harder to read today.
• The pattern is being forced to fit. If you find yourself adding empty methods or instanceof checks to make the shape work, the problem is not the one the pattern was designed for.

Patterns are best discovered in your code, not imposed on it: write the simple version first, and refactor towards a pattern when the second or third variation arrives and the duplication or the growing conditional shows you which one fits. Each lesson in this chapter includes a "when to avoid" list for that reason.

5. Mental-model summary

6. Gotcha checklist

✅ Check yourself

One check per objective. Answer before you open anything.

📚 Sources

1. Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994), ch. 1, including §1.1 "What Is a Design Pattern?".
2. Christopher Alexander, Sara Ishikawa and Murray Silverstein, A Pattern Language: Towns, Buildings, Construction (Oxford University Press, 1977).
3. Peter Norvig, "Design Patterns in Dynamic Languages" (1996) — https://norvig.com/design-patterns/
4. java.util.ArrayList and java.util.ConcurrentModificationException, Java SE 21 API — https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/ConcurrentModificationException.html
5. Python 3 documentation, "The for statement" — https://docs.python.org/3/reference/compound_stmts.html#the-for-statement

Your Turn

Before you move on, check your understanding with the coach — explain the idea, apply it, weigh the trade-offs, then defend your reasoning.