Design Patterns¶

"Design patterns are typical solutions to common problems in software design. Each pattern is like a blueprint that you can customize to solve a particular design problem in your code."

What Are Design Patterns?¶

A design pattern is a reusable, named solution to a recurring problem in software design. It is not a finished piece of code — it's a description of how to solve a problem in many different situations.

Pattern vs Algorithm vs Library¶

Concept	What it is	Granularity
Algorithm	A precise, deterministic recipe (e.g., quicksort)	Low-level, language-agnostic logic
Design Pattern	A high-level blueprint for a solution	Mid-level, must be implemented for each context
Library / Framework	Concrete reusable code	High-level, ready to use

Two engineers implementing the same pattern can produce very different code, but they will recognize each other's structure and intent.

A Brief History¶

Year	Event
1977	Christopher Alexander (architect) publishes A Pattern Language — patterns for buildings and towns. Software pioneers borrow the idea.
1987	Kent Beck and Ward Cunningham apply patterns to Smalltalk UI development.
1994	The "Gang of Four" — Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides — publish Design Patterns: Elements of Reusable Object-Oriented Software. This book defines the canonical 23 patterns.
2004	Head First Design Patterns makes the GoF accessible to a wider audience.
Today	Patterns remain a shared vocabulary — the foundation of communicating design across teams.

This roadmap covers all 23 patterns from the GoF book. The Interpreter pattern — omitted on refactoring.guru — is included here because it remains conceptually important (regex engines, SQL WHERE evaluators, mini DSLs, rule engines) and is the natural dual of Visitor.

Three Categories¶

The GoF book organizes patterns by intent — the kind of problem they solve.

graph TD DP[Design Patterns] DP --> C[Creational 5 patterns How objects are created] DP --> S[Structural 7 patterns How objects are composed] DP --> B[Behavioral 11 patterns How objects communicate]

Category	Concern	Pattern Count	Examples
Creational	Object creation mechanisms	5	Singleton, Factory Method, Builder
Structural	Object composition / structure	7	Adapter, Decorator, Proxy
Behavioral	Object communication / responsibilities	11	Strategy, Observer, Interpreter

Why Design Patterns Matter¶

"Patterns are a toolkit of solutions to common problems in software design. They define a common language that helps your team communicate more efficiently."

Concretely, patterns help you:

Speak a shared language — saying "use a Strategy here" conveys structure, intent, and tradeoffs in two words
Avoid reinventing wheels — proven solutions, battle-tested for decades
Reason about design — patterns make consequences (coupling, extensibility) explicit
Read other people's code — once you recognize the pattern, you understand the architecture
Onboard juniors — pattern names are searchable; "what is a Decorator?" gets a clear answer

Cautions¶

Don't shoehorn patterns into a problem — a pattern is a tool, not a goal
Adding a pattern always adds complexity — apply only when the gain (flexibility, decoupling, clarity) outweighs the cost
Some patterns are language-specific anti-patterns — e.g., Singleton in test-heavy code; Visitor in dynamically-typed Python
Modern languages reduce the need for some patterns — Python's first-class functions remove the need for Command/Strategy in many cases

How to Pick a Pattern (Decision Guide)¶

Ask the question that matches your situation:

Question	Look at
"How do I create this object without coupling to its concrete class?"	Creational — Factory Method, Abstract Factory, Builder
"How do I make incompatible interfaces work together?"	Structural — Adapter
"How do I add behavior to an object without subclassing?"	Structural — Decorator, Proxy
"How do I work with a tree of objects uniformly?"	Structural — Composite
"How do I substitute an algorithm at runtime?"	Behavioral — Strategy, State
"How do I notify multiple objects when something happens?"	Behavioral — Observer
"How do I undo an action?"	Behavioral — Command + Memento
"How do I traverse a collection without exposing its internals?"	Behavioral — Iterator
"How do I avoid a tangle of mutual references?"	Behavioral — Mediator

Pattern Relationships¶

Many patterns are related, complementary, or contrasting. A few key contrasts to keep in mind early:

Often Confused	Difference
Strategy vs State	Strategy: client picks the algorithm. State: state transitions are managed internally.
Decorator vs Proxy	Decorator: adds behavior. Proxy: controls access (lazy, security, remote).
Decorator vs Adapter	Decorator: same interface, more behavior. Adapter: different interface, same behavior.
Factory Method vs Abstract Factory	Factory Method: one product, subclass decides. Abstract Factory: family of products, swap whole family.
Facade vs Mediator	Facade: one-way simplification. Mediator: many-to-many coordination.
Command vs Memento	Command: encapsulates an action. Memento: encapsulates a state snapshot.

Browse by Category¶

Creational Patterns — Factory Method, Abstract Factory, Builder, Prototype, Singleton
Structural Patterns — Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
Behavioral Patterns — Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor, Interpreter