A design pattern is a named solution to a problem that keeps showing up in object-oriented code. Knowing the names helps you talk about a design quickly, and knowing the problem each one solves helps you pick the right one. Do not use a pattern because it exists. Use it when you feel the pain it removes.
Each link below opens a lesson with the problem, a before and after class diagram, a step-by-step flow of the calls and code in Python and Java.
SOLID principles
Five habits that keep classes easy to change. Patterns are just these habits with names.
| Pattern | What it does |
|---|---|
| Single Responsibility | A class should have one reason to change |
| Open / Closed | Open for extension, closed for modification |
| Liskov Substitution | A subclass must work wherever its parent is expected |
| Interface Segregation | Many small interfaces beat one fat one |
| Dependency Inversion | Depend on abstractions, not on concrete classes |
Creational patterns
How objects get made without the caller knowing the messy details.
| Pattern | What it does |
|---|---|
| Singleton | Exactly one instance, reachable from anywhere |
| Factory Method | Let a method decide which class to create |
| Abstract Factory | Create whole families of matching objects |
| Builder | Build a complex object one step at a time |
| Prototype | Make new objects by copying an existing one |
Structural patterns
How classes and objects are put together into bigger, flexible shapes.
| Pattern | What it does |
|---|---|
| Adapter | Make an incompatible interface fit the one you expect |
| Bridge | Split a thing into two parts that can vary on their own |
| Composite | Treat one item and a group of items the same way |
| Decorator | Add features to an object by wrapping it |
| Facade | One simple front door for a complicated subsystem |
| Flyweight | Share the common part of many similar objects |
| Proxy | A stand-in that controls access to the real object |
Behavioral patterns
How objects talk, share work and change behaviour at run time.
| Pattern | What it does |
|---|---|
| Chain of Responsibility | Pass a request along handlers until one deals with it |
| Command | Turn a request into an object you can store, queue or undo |
| Interpreter | Represent a small language as classes and evaluate it |
| Iterator | Walk through a collection without knowing how it is stored |
| Mediator | Let objects talk through a middleman, not to each other |
| Memento | Save a snapshot of an object so you can restore it later |
| Observer | Tell everyone who is interested when something changes |
| State | An object changes its behaviour when its state changes |
| Strategy | Swap an algorithm without changing the code that uses it |
| Template Method | Fix the steps of a recipe, let subclasses fill in some of them |
| Visitor | Add new operations to a set of classes without editing them |
Which ones to learn first
If you are short on time, learn the SOLID principles first, then Strategy, Observer, Factory Method, Decorator and Singleton. These appear most often in interviews and in real code.
See the full low-level design track, or read HLD vs LLD to see how this fits next to system design.