Software design patterns
Design patterns are named, reusable solutions to recurring design problems. Here are the three categories, the ones you’ll actually use, and when not to.
What a design pattern is
A design pattern is a named, reusable solution to a problem that comes up again and again in software design. Patterns aren’t code you copy, they’re shapes you recognize and a shared vocabulary for talking about structure. The classic catalog is the 23 patterns from the 1994 “Gang of Four” book, grouped into three categories by what they’re about: creating objects, composing them, or coordinating their behavior.
Creational, how objects are made
- Factory Method: defer which concrete class to instantiate to a subclass or a function.
- Abstract Factory: create families of related objects without naming concrete types.
- Builder: assemble a complex object step by step, separating construction from representation.
- Singleton: guarantee one instance with a global access point. (Useful occasionally; often overused, it’s global state in disguise.)
- Prototype: create new objects by cloning an existing one.
Structural, how objects are composed
- Adapter: wrap an interface so two incompatible types can work together.
- Decorator: add behavior to an object by wrapping it, without subclassing.
- Facade: present one simple interface over a complex subsystem.
- Composite: treat individual objects and groups of them uniformly (trees).
- Proxy: stand in for another object to control access, add caching, or defer work.
Behavioral, how objects coordinate
- Observer: notify dependents automatically when something changes (the heart of event systems).
- Strategy: make an algorithm interchangeable by encapsulating it behind an interface.
- Command: turn a request into an object you can queue, log, or undo.
- Iterator: traverse a collection without exposing its internals.
- State: let an object change behavior when its internal state changes.
When a pattern helps, and when it hurts
A pattern earns its keep when it names a structure your code already needs and makes intent obvious to the next reader. It hurts when you reach for it first and bend the problem to fit, that’s how a three-line need becomes five interfaces and a factory. The honest rule: let patterns emerge from the problem. Solve it plainly, and when you notice you’ve reinvented Observer or Strategy, adopt the name. Many patterns also relax in modern languages, first-class functions make Strategy and Command nearly free, for instance.
FAQ
Do I need to memorize all 23?
No. Know the handful you’ll actually use, Factory, Builder, Adapter, Decorator, Facade, Observer, Strategy, and recognize the rest when you see them.
Why is Singleton controversial?
It’s global mutable state with a friendly name, convenient, but it hides dependencies and makes testing and concurrency harder. Use it deliberately, not by default.
Are design patterns language-specific?
The catalog came from C++/Smalltalk, but the patterns are language-agnostic shapes. Their weight varies, features like closures and interfaces make some patterns trivial in modern languages.
Related
Patterns build on OOP concepts; see also concurrency and the full Reference.