How to learn design patterns

What a pattern is

A design pattern is a named solution to a recurring design problem, together with when it applies and what it costs. The famous catalogue, Design Patterns (1994) by Gamma, Helm, Johnson and Vlissides ("the Gang of Four"), described 23 patterns in object-oriented software.

Patterns give you three things:

1. A shared vocabulary: "use a factory here" communicates a whole idea in a few words.
2. Proven structures you do not have to invent under pressure.
3. Awareness of trade-offs, since each pattern comes with consequences.

They are not copy-paste code, and not a goal in themselves.

The three families

100%

Figure SDA-SDE-01-1 · The three families · © forcsguy.com

The catalogue at a glance

Pattern	One-line idea	Typical use
Factory Method	A method decides which concrete class to create	Create objects without hard-coding the class
Abstract Factory	Create families of related objects	Themes, platform-specific widget sets
Builder	Build a complex object step by step	Objects with many optional parts
Prototype	Create objects by copying an existing one	Costly-to-create objects
Singleton	Exactly one instance, globally reachable	Rare; often better as dependency injection
Adapter	Make one interface look like another	Wrap a third-party library
Bridge	Separate an abstraction from its implementation	Several dimensions of variation
Composite	Treat a tree of objects like a single object	File systems, UI trees
Decorator	Add behaviour by wrapping an object	Logging, caching, compression layers
Facade	A simple front for a complex subsystem	A clean API over messy internals
Flyweight	Share common state to save memory	Many similar small objects
Proxy	A stand-in that controls access	Lazy loading, access control, remote calls
Strategy	Swap algorithms behind an interface	Pricing rules, sorting choices
Observer	Notify dependants when something changes	Events, UI updates
Command	Turn a request into an object	Undo, queues, macros
State	Behaviour changes with internal state	Workflows, connections
Template Method	A skeleton algorithm with customisable steps	Frameworks, hooks
Iterator	Walk a collection without exposing its structure	Loops over any collection
Chain of Responsibility	Pass a request along handlers until one handles it	Middleware, validation chains
Mediator	One object coordinates others	Chat rooms, form logic
Memento	Save and restore an object's state	Undo, snapshots
Visitor	Add operations to a structure without changing it	Compilers, reports over trees
Interpreter	Evaluate sentences of a small language	Rules, expressions

The next lessons explain the most useful ones with examples.

A practical way to learn

1. Learn the problems first. Each pattern exists because of a pain: rigid code, duplicated code, tangled dependencies. Understand the pain, then the cure.
2. Start with the ones you already use without naming them: Iterator (every for...of), Observer (event listeners), Decorator and Chain of Responsibility (middleware), Strategy (a function you pass in).
3. Implement each once, small, in your language, and write what you gave up.
4. Spot them in real code: frameworks and standard libraries are full of patterns.
5. Refactor towards a pattern when the code hurts, rather than starting with one.

Patterns look different in different languages

In languages with first-class functions, several patterns shrink to a function: Strategy is a function argument, Command is a closure, Observer is a callback list, and Template Method is passing the varying step. In dynamic languages, Factory and Adapter are often trivial. Learn the intent, then use the lightest form your language allows.

Anti-patterns to avoid

• Pattern overload: five layers of abstraction for a feature that needs ten lines.
• Singleton as global state: hides dependencies and makes testing hard.
• Naming something by the pattern, not by what it does (ManagerFactoryProvider).
• Applying a pattern "in case": wait until the second or third time you need the flexibility.

Real-world reading