rgoussu.dev
rgoussu@goussu: ~/library/applicative-architecture
❯ ~/library/applicative-architecture cat design-patterns.md

Design patterns

# The GoF catalog read critically — which patterns still matter, which dissolved into languages, and the modern vocabulary that replaced the rest.

Conceptsaved 2026-08-08updated 2026-08-20 #design-patterns#design#craft#gof

Overview

Design patterns are named solutions to recurring design problems — a shared vocabulary more than a toolkit. The Gang of Four catalog (1994) is the canon, but thirty years on it deserves a critical read: some patterns remain daily bread, many dissolved into language features (lambdas ate Strategy and Command; iteration is syntax now), and some were workarounds for the weaknesses of 1990s C++/Java. Knowing the names is table stakes; knowing which ones earn their complexity today is the skill.

Key points

  • The survivors (use weekly): Strategy (behavior as a parameter — now often just a function), Factory Method / builder-style construction, Adapter (the heart of hexagonal architecture), Decorator (middleware chains, io.Reader wrapping), Observer (as events/listeners — the reactive lineage), Facade, Template Method's modern inversion (pass a function instead of subclassing).
  • Dissolved into languages: first-class functions replaced Strategy/Command boilerplate; Iterator is for … of / Iterable; Prototype is irrelevant outside clone-semantics languages; Singleton survives mostly as an anti-pattern — hidden global state; prefer one instance wired by injection.
  • Composition over inheritance is the deepest single lesson of the book — stated in its introduction and routinely skipped by readers heading straight for the catalog.
  • The modern vocabulary extends beyond GoF: dependency injection, Repository and Unit of Work (persistence), Circuit Breaker/Retry (resilience patterns), MapReduce-style pipelines, functional patterns (map/filter/fold, Option/Result instead of null/exceptions), and language-idiomatic forms — patterns are language-relative (Peter Norvig's observation that dynamic languages make many invisible).
  • Pattern pathology: patterns are discovered in refactoring, not installed up front — "pattern-driven design" produces AbstractSingletonProxyFactoryBean. Name the pattern when the problem shows up; never introduce indirection speculatively.
  • Anti-pattern literacy: god object, anemic domain model (per DDD), golden hammer, premature abstraction — recognizing these is as valuable as the catalog itself.
  • To explore: Head First Design Patterns for intuition, POSA (architecture-scale patterns), enterprise integration patterns (Hohpe) as the messaging-world sibling.

Practice

  • Design patterns catalog (source) — recognition drills: for each pattern, name a place your current codebase uses it — or should, or shouldn't.
  • Parrot Refactoring Kata (source) — watch Strategy/polymorphism emerge from Replace Conditional with Polymorphism instead of being installed up front.
  • Racing Car katas (source) — SOLID violations to refactor away; Adapter and dependency inversion in miniature.
  • Gilded Rose — legacy rescue (exercise) — a pattern discovered under refactoring pressure — exactly how patterns legitimately appear.

Related