principle-design-patterns

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 one.

Facade

Problem: a subsystem has too many moving parts for its callers. Use when: simplifying a complex API for the common 80%. Overkill when: the facade just forwards one call.

Template Method

Problem: the skeleton of an algorithm is fixed but steps vary. Use when: several variants share a clear sequence. Overkill when: the sequence is two steps. Warning: easy to abuse — prefer Strategy when steps are independent.