Design Patterns

Identify the right pattern for a problem, explain it precisely, and apply it with minimal disruption to the existing codebase. Patterns are vocabulary for communicating structure — not solutions to be force-fitted.

Skill workflow — patterns often follow from structural review: refactoring (prepare the ground for a pattern) → design-patterns (apply the pattern) → adr (record the architectural decision)

Philosophy

Patterns are named solutions to recurring design problems in a given context. Their value is not the solution itself — it's the name. When you say "Decorator", everyone on the team knows the structure, the intent, and the tradeoffs. Bad pattern usage happens in two ways:

• Over-application — using a pattern because it's a pattern, not because it solves a real problem. The Pattern Astronaut disease.
• Misidentification — implementing something that looks like a pattern but violates its invariants (e.g., a "Factory" that also manages object state — that's not a Factory).

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem." — Christopher Alexander (precursor to GoF)