Card 04/ 08
Design Patterns and SOLID: Which Principle Each Pattern Serves
Strategy is open/closed with a name; Adapter is dependency inversion at a boundary.
Most design patterns are recurring ways of applying the SOLID principles to a particular problem. A principle says what good structure looks like; a pattern is a tested arrangement of classes that achieves it in a situation that comes up often. This card connects the two, so that every pattern you meet has a reason you already know.
The five principles, in one line each: single responsibility, a class has one reason to change; open/closed, new behaviour arrives as new code rather than edits; Liskov substitution, a subtype keeps its parent's promises; interface segregation, no class depends on methods it does not use; dependency inversion, business code depends on interfaces it owns rather than on concrete details.
Take Strategy. A checkout needs several discount rules, and new ones arrive every quarter. Open/closed says a new rule should be a new class, not a new branch in the checkout. Strategy is how: the checkout holds a Discount interface, each rule implements it, and adding a rule touches nothing that already works.
| Pattern | Principle it serves | How |
|---|---|---|
| Strategy | Open/closed | A new algorithm is a new class behind an interface the context already uses. |
| Adapter | Dependency inversion | The client owns the interface; the adapter makes a third-party class implement it. |
| Decorator | Open/closed, single responsibility | Each added behaviour is its own wrapper class, and the wrapped class is never edited. |
| Observer | Dependency inversion | The subject depends on an observer interface, never on the classes that listen. |
| Factory Method | Dependency inversion | The code that uses an object depends on its interface, and only the factory names the concrete class. |
| Composite | Liskov substitution | A group and a single item can replace each other wherever the shared interface is used. |
| Command | Single responsibility | The object that triggers a request is separated from the object that carries it out. |
The table gives each pattern's main principle, not its only one. Strategy also inverts a dependency, and most patterns satisfy two or three principles at once. Facade is an honest exception: it lowers coupling by giving callers one class instead of many, which no single letter of SOLID names.
The connection works in both directions. Reading a pattern, ask which principle it serves, and you will know which change it is protecting against. Facing a principle you cannot see how to apply, ask which pattern applies it to a problem like yours.
Seen this way, the patterns are no longer 23 things to memorise. Each one is a principle applied to a problem shape, and if you hold the principle, the pattern's structure is easier to rebuild from memory than to recall.
← → move through sections and cards