Design Patterns

Definition

A design pattern is a named, described solution to a problem that recurs in a context. The catalogue — strategy, observer, adapter, factory, decorator, and the rest — is less important than the idea that recurring solutions can be named.

The real value: vocabulary

"Use a strategy here" communicates a structure in three words to anyone who shares the vocabulary. That compression is the main benefit, and it operates in design discussion, code review and documentation.

The architectural equivalents — circuit breaker, bulkhead, saga, outbox, strangler fig, sidecar — do exactly the same work at a different altitude, and they are considerably more valuable to an architect than the object-level catalogue.

Where patterns do harm

Applied as goals. A design is not better for containing patterns. The classic failure is a factory producing a strategy configured by a builder, for a system with one implementation of everything.

Compensating for language weakness. Several classic patterns exist to work around limitations of 1990s object-oriented languages. In a language with first-class functions, "strategy" is passing a function, and naming it a pattern adds ceremony. Applying the full pattern structure in such a language is cargo-culting.

Locking in structure early. A pattern introduced before the variation it accommodates has appeared is speculative generality — indirection paid for now against an option that may never be exercised.

The healthy relationship

Recognise the pattern when the problem appears; do not seek the problem to justify the pattern. Write the direct code, and when a second and third variation arrive, the refactor to a named structure is obvious, mechanical and safe.

Patterns are most useful read backwards: not "which pattern shall I apply" but "the shape I have arrived at is called X, which tells me what usually goes wrong with it next."

Failure scenarios

• Speculative generality — abstractions for variations that never arrive.
• Pattern names in class names (OrderStrategyFactoryImpl) as a substitute for describing what the code does.
• Patterns as a review checklist, producing ceremony rather than clarity.
• Missing the architectural patterns while mastering the object-level ones — the former have far larger consequences.

Interview question

"When does introducing a design pattern make a codebase worse?"