Design Patterns

The “design patterns” movement was an important step forward in object-oriented design. The 1994 book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides carried it into the mainstream. Its four authors became known as the “Gang of Four”¹. I refer to that book as GoF Design Patterns, and use design patterns for the concept.

GoF Design Patterns shows 23 solutions to particular classes of problems, along with one or more examples for each, typically in C++ but sometimes in Smalltalk. Many of those examples inspired the ones in this part of the book. This chapter introduces the concepts. One listing makes the point, and the chapters that follow supply the rest of the code.

What Is a Pattern?

Initially, you can think of a pattern as an especially clever and insightful way of solving a particular class of problems. Many people have worked out all the angles of a problem and have come up with the most general, flexible solution. You may have seen and solved something like it before, but your solution probably lacks the completeness a pattern embodies.

That completeness has a failure mode. Once you know a catalog of patterns, that catalog tempts you to treat it as a checklist, and to install patterns as proof of sophistication. A pattern earns its place only when you have the problem it solves. If nothing varies, you do not need machinery for isolating variation.

Although they’re called “design patterns,” they apply beyond design. Because a pattern translates directly into code, you might expect it to appear no earlier than low-level design. But a pattern embodies a complete idea within a program, so it can appear at the analysis phase or high-level design phase, where you are still describing what the system does rather than how to build it. It appears at every level, and you often discover that you need one only once you reach the code.

The basic concept of a pattern is also the basic concept of program design: adding a layer of abstraction. Whenever you abstract something, you isolate particular details. One of the most compelling motivations for abstraction is to separate things that change from things that stay the same. Once you find a part of your program that’s likely to change, patterns can prevent those changes from causing secondary effects throughout your code. That isolation makes the code cheaper to maintain and usually simpler to understand.

Isolation has a price. An abstraction is a bet about which details no caller will ever need, and a good abstraction does more than hide those details. It erases them. Code outside the boundary cannot recover information the boundary discards, so a caller that turns out to need an erased detail cannot work around the interface. Someone must reopen the interface. The art of design lies in guessing well about which details you can hide and which you must expose.

Erased details are also where scaling limits come from. Every abstraction discards something (a copy, an ordering, a lookup behind an attribute) that costs nothing at the size you built it. A growing system eventually reaches the size where one discarded detail dominates, and the layer that made the code simple now stands between you and the fix. This is one reason Performance tells you to measure at a realistic size rather than trust a small trial.

Often, the most difficult part of developing an elegant and cheap-to-maintain design is discovering what I call “the vector of change” (here, “vector” means a direction of change, not an array of numbers). You look for the most important thing that changes in your system, because that is where your greatest cost lies. Once you discover the vector of change, you have the focal point around which to structure your design.

You discover a vector of change. You do not predict it. Guessing at it up front often adds complexity to allow flexibility in a direction nobody uses. The second time a requirement shifts the same part of the design, you have evidence.

Design patterns isolate changes in your code. You have seen some design patterns in this book. For example, you can think of inheritance as a design pattern (albeit one the language builds in). It lets you express differences in behavior (that’s the thing that changes) in objects that all have the same interface (that’s what stays the same). Composition also qualifies as a pattern, since it lets you change, dynamically or statically, the objects that implement your class, and thus the way that class works.

Another pattern that appears in GoF Design Patterns is the Iterator. An iterator lets you hide the particular implementation of the container as you step through it. You can write generic code that operates on all the elements in a sequence without regard to how that sequence stores them. The code works with any object that produces an iterator.

Pattern Evolution

A pattern arrives in stages, each more general than the last:

1. Idiom: how you write code in a particular language to do this particular type of thing. This could be something as common as the way you step through an array in C (without running off the end).
2. Specific Design: the solution that arose to solve this particular problem. This might be a clever design, but it doesn’t try to be general.
3. Standard Design: a way to solve every problem of that kind, not just the one in front of you. A design that has become more general, typically through reuse.
4. Design Pattern: how to solve an entire class of similar problems. This usually appears only after you apply a standard design several times, and then see a common pattern across those uses.

In Python terms: with open(...) for guaranteed cleanup is an idiom, stage one, meaningless outside a language that provides with. A dictionary mapping one program’s shape names to its shape classes is a specific design, stage two. The same dictionary is a standard design, stage three, once each subclass registers itself as its class statement runs, so adding a type never means editing the factory (Factory builds both). Template Method is a design pattern, stage four: a shape of solution you could build in any language with polymorphism.

The stages are a history, not a ranking. Patterns are subtle and appear over time, so leave a solution at the stage it has reached rather than forcing it toward a design pattern.

The progression runs downward too. A pattern a language builds in drops back to stage one, and the programmers who arrive next learn it as syntax rather than as a design. Stepping through a container is stage one in Python and was stage four in the GoF Design Patterns examples.

When a Pattern Dissolves

A pattern is often a sign of something missing in a language. Programmers wrote the same scaffolding often enough that it acquired a name, and the pattern exists because the language leaves that scaffolding for them to write.

A language can supply that missing piece in two ways. Sometimes a language grows the feature and the pattern dissolves into it². Iterator is the clear case. It was implicit in the for loop from the start, and Python 2.2 made it a protocol the language calls on your behalf. More often the language had the piece all along, and the pattern came from a language that didn’t. Strategy and Command shrink to passing a function, because a Python function is an object (Function Objects shows both). A Factory becomes a dictionary, because a class is an object too. Singleton becomes a module, because Python imports each module once and caches it.

Here is the whole of a Strategy in Python:

# strategy_is_a_function.py
from collections.abc import Callable

def apply(nums: list[int],
          how: Callable[[list[int]], int]) -> int:
    return how(nums)
print(apply([3, 1, 2], max), apply([3, 1, 2], sum))
#: 3 6

The classic form declares a Strategy interface, writes one class per algorithm, and adds a context class to hold the chosen one. The how parameter replaces all three.

This listing shows only the shape. Nobody designs a Strategy class hierarchy around calling max or sum; Function Objects works through a case with a real motivation.

That replacement is why the chapters ahead keep asking the question Rethinking Objects posed: how much of each pattern’s machinery does Python still need, and how much of it becomes functions, data, and protocols?

Pattern Taxonomy

GoF Design Patterns discusses 23 patterns and sorts them under three purposes, each named for the aspect that can vary:

1. Creational: how to create an object. When you isolate the details of object creation, your code stops depending on which object types exist, and adding a type leaves that code unchanged. Singleton counts as a Creational pattern, and Factory covers the other four: Factory Method, Abstract Factory, Prototype, and Builder.
2. Structural: how objects connect to other objects, arranged so that changes in the system leave those connections alone. Surrogate, Changing the Interface, Flyweight, Decorators, and the Composite half of Composite and Interpreter cover the structural patterns in this book.
3. Behavioral: objects that handle particular types of actions within a program. These encapsulate processes such as interpreting a language, fulfilling a request, moving through a sequence (as in an iterator), or implementing an algorithm. Most of the patterns in this book are behavioral: Iterator, Template Method, Function Objects (Command, Strategy, and Chain of Responsibility), Observer, Visitor, Memento, State, and Interpreter, though State appears beside Proxy and Interpreter beside Composite, for the reason that closes this section.

The catalog above is GoF’s. Patterns from outside it, like the Null Object that Rethinking Objects builds, appear in the Pattern Catalog.

I’ve found the GoF Design Patterns classification too obscure, and not always helpful. Certainly, the Creational patterns are straightforward. How will you create objects? This is a normal question, and the name brings you right to that group of patterns. But I find Structural and Behavioral far less useful distinctions. I have not been able to look at a problem and say “clearly, you need a structural pattern here,” so that classification doesn’t lead me to a solution (I’ll readily admit that I may be missing something here).

Patterns often resemble each other more in their implementations than the GoF Design Patterns categories suggest, and this book groups them by that resemblance. Surrogate treats Proxy and State as one front-object structure. Function Objects treats Command, Strategy, and Chain of Responsibility as one function-passing structure. Composite and Interpreter treats both of its patterns as one recursive-data structure. When two patterns share a structure, learning one teaches you most of the other, and the remaining difference is intent.

Design Principles

Design principles are at least as important as design patterns, but they do a different job. A pattern is a shape of solution. A principle is a test you apply to whatever shape you chose: a claim you can hold the design up against. Most hold for any code, but Reflexivity and the Law of Demeter assume classes and objects. The list is a reference: later chapters name a few of these principles when a design turns on them, and the rest are here for your own designs.

• Principle of least astonishment (don’t be astonishing).
• Make common things easy, and rare things possible.
• Consistency. Every inconsistency in a design is one more arbitrary rule to remember. The more random rules you pile onto the programmer, rules that have nothing to do with solving the problem at hand, the slower the programmer works. The cost does not grow one rule at a time. The rules interact.
• Liskov Substitution Principle (LSP): a subtype must work anywhere code expects its base type, as Rethinking Objects describes.
• Law of Demeter: a.k.a. “Don’t talk to strangers.” A method should talk only to itself, its own attributes, its parameters, and objects it creates, not to the internals of objects it reached through something else. The Law of Demeter is another way to say “minimize coupling.”
• Independence or Orthogonality. Express independent ideas independently. Orthogonality complements separating what varies from what stays the same, and is part of the Low-Coupling-High-Cohesion message: few connections between parts, and one subject per part. Rethinking Objects argues for composition on those grounds.
• Managed Coupling. Simply declaring that a design should have “low coupling” is usually too vague. Coupling happens, so acknowledge it and control it: say “coupling can cause problems” and compensate for those problems with a well-considered design or pattern.
• Design the communication, not the parts. Alan Kay, on what object orientation was for: “The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.”³ A Protocol is that design made literal: it names what a caller needs from the object on the other side of a call, and says nothing about what that object is. Rethinking Objects builds on this, and Stateless moves the same declaration into a function’s signature, where Need names what the function requires of its surroundings. This gives Managed Coupling its target: not the least coupling, but coupling you can read.
• Subtraction: a design is complete when you cannot take anything else away⁴.
• Simplicity before generality⁵. A common problem we find in frameworks is that they aim to be general purpose without reference to actual systems. This leads to a dizzying array of options that are often unused, misused or not useful. However, most developers work on specific systems, and the quest for generality does not always serve them well. The best route to generality is through understanding well-defined specific examples. This principle acts as the tie breaker between otherwise equally viable design alternatives. The simpler solution may also turn out to be the more general one. Pattern Refactoring works through a case of this, one requirement at a time.
• Reflexivity. One abstraction per class, one class per abstraction. Also goes by Isomorphism.
• Once and once only: Avoid duplication of logic and structure where the duplication is not accidental, i.e., where both pieces of code express the same intent for the same reason.
• Make things as immutable as possible, as Data Classes as Types describes.
• Make functions pure whenever you can, as Pure Functions describes.

You can hold this handful of fundamental ideas in your head while analyzing a design.

Reading the Chapters Ahead

Most of the chapters ahead take a pattern, or a family of patterns that share a structure, and ask three questions of it. What varies and what stays the same? That names the problem the pattern exists to solve. How much of the answer does Python supply on its own? That decides how much remains for you to write. What remains after you subtract Python’s share? That remainder is worth learning, and it is usually the intent rather than the structure.

A pattern that subtracts to nothing was not a mistake. It was the right answer for a language missing the piece Python has.

Part III closes with a Pattern Catalog, a name-and-intent index of the wider literature, with a link to this book’s coverage wherever it exists.

Exercises

1. Pick a program you have written that changed more than once. Name its vector of change: the thing that shifted every time. Say which part of the design absorbed the change, and which parts you edited by hand.
2. Take a pattern you know from another language and list its parts: the classes, the interfaces, and the methods its usual form requires. Cross out every part Python supplies without your writing it. Describe what remains in one sentence.
3. Apply Subtraction to a design of your own. Remove one class, one interface, or one level of inheritance, and say what stopped working. If nothing did, leave it out.