4.4 Design Patterns And SOLID In Practice
Design patterns are named solutions to recurring design pressure. SOLID principles are heuristics for managing dependency and change. Both are useful when applied to a real force, and harmful when used as decoration.
Pattern families
Creational patterns manage object creation. Examples include Factory and Builder.
Structural patterns manage relationships between parts. Examples include Adapter, Facade, and Decorator.
Behavioral patterns manage communication and responsibility. Examples include Strategy, Observer, Command, and Template Method.
The pattern name is less important than the pressure:
- Do callers need to stop depending on concrete classes?
- Do we need to swap algorithms?
- Do we need to wrap an external API?
- Do we need to notify multiple subscribers?
- Do we need to compose behavior without a giant inheritance tree?
SOLID as change heuristics
| Principle | Practical reading |
|---|---|
| SRP | A module should have one main reason to change |
| OCP | Add common variations without editing stable core logic |
| LSP | Subtypes should not surprise callers |
| ISP | Do not force clients to depend on methods they do not use |
| DIP | High-level policy should not be locked to low-level details |
The pattern tax
Patterns add names, files, indirection, and testing surface. Pay that tax only when it buys flexibility you can explain.
Bad reason: "This looks more enterprise."
Good reason: "We add a new pricing rule every month; Strategy lets each rule be tested and deployed with less risk."