principle-design-patternslisted

# Design Patterns — the ones worth knowing Patterns are vocabulary, not goals. Reach for one only when the problem it solves is actually present. ## Strategy **Problem:** an algorithm varies independently of its caller. **Use when:** multiple interchangeable behaviors selected at runtime (pricing rules, compression, sort orders). **Overkill when:** there is only one strategy. **Modern alternative:** a first-class function or lambda. ## Factory Method **Problem:** construction is non-trivial or must be swappable. **Use when:** the concrete type depends on input or config. **Overkill when:** `new Thing()` works and always will. **Modern alternative:** a constructor function plus DI at the composition root. ## Observer **Problem:** many objects need to react to a state change. **Use when:** loose coupling between emitter and listeners (UI, domain events). **Overkill when:** one listener, ever — call it directly. **Modern alternative:** language-native events, reactive streams, domain events on a bus. ## Decorator **Problem:** add behavior without subclassing the world. **Use when:** stacking optional behavior — caching, logging, retries around a core call. **Overkill when:** no composition, one behavior. **Modern alternative:** middleware chains, higher-order functions. ## Adapter **Problem:** two interfaces should work together but don't. **Use when:** integrating a third-party or legacy API into your domain types. **Overkill when:** you control both sides — just change o