Judgement over catalogue.
WHAT TO DO FIRST
Write the straightforward solution.
WHY
Most code needs no pattern, and the direct version is usually clearest.
WHEN TO INTRODUCE A PATTERN
When the problem it solves has actually appeared.
WHAT THAT LOOKS LIKE
The third time the same variation is needed Conditional chains selecting behaviour Difficulty testing because dependencies are created internally
WHAT TO AVOID
Designing around patterns before writing anything Naming classes after patterns unnecessarily Applying a pattern because a reviewer mentioned it
WHAT TO ASK OF ANY PATTERN YOU INTRODUCE
Does this make the code easier to change, or only more elaborate?
WHAT INDIRECTION COSTS
Every layer is another step when reading and debugging.
WHAT TO PREFER
The smallest amount of structure that solves the problem.
WHAT TO REFACTOR TOWARD
Patterns, when the need emerges, rather than designing to them initially.
WHY
The need reveals which pattern actually fits, which anticipation does not.
WHAT MATTERS MORE THAN PATTERNS
Clear names, small units, and boundaries in sensible places.
