A Design Patterns Checklist

Before, during and after

Before: what exactly varies or is likely to change, and is that change real or speculative? Is there a language feature (functions, modules, generators, union types) that solves it more simply? During: does the pattern's name match its intent, so the next reader recognises it? Are dependencies explicit and injected rather than global? Is the abstraction small and focused? After: is the code easier to test and change than the simple version, and would you remove the pattern if the variation disappeared? Patterns are tools for managing change; measure them by how much change they make easier.

The checklist

Use it in design reviews and pull requests.

[ ] the problem is real: at least two concrete variants or a known upcoming change
[ ] a simpler language feature (function, module, options object, union) was considered
[ ] the pattern name matches its intent and is used in naming or comments
[ ] dependencies are injected at a composition root, not reached through globals
[ ] interfaces are small; no god objects or "manager" classes doing everything
[ ] behaviour depending on lifecycle is modelled as an explicit state machine
[ ] third-party APIs are wrapped behind adapters
[ ] cross-cutting concerns use decorators or middleware with a documented order
[ ] the design is easier to test (fakes, in-memory implementations)
[ ] you would remove the abstraction if the variation went away

Refactor towards patterns

Most good pattern usage appears during refactoring, when the code shows you where variation lives. Write simple code first and let the pattern emerge.

Quick check: Which is the best reason to introduce a pattern?

• It makes the codebase look more professional
• The pattern appears in a well-known book
• There is real, observed variation or change that the pattern makes easier to handle
• Every class should implement at least one pattern