Design Patterns

A pattern-recognition lens distilled from Head First Design Patterns (Freeman & Robson, 2nd ed). The goal is not to apply patterns — it's to see where a pattern naturally fits and where it doesn't, then reach for the simplest thing that solves the real problem.

The guardrail comes first

The book's most important lesson lands in its final chapter, not its first: most code should not use a named pattern.

• Keep it simple (KISS). When you design, solve the problem the simplest way possible. The goal is simplicity, not "how can I apply a pattern here?" A plain function, a map, or an early return is often the right answer, and other developers will admire the simplicity.
• Patterns are not free. Each one adds classes, indirection, and layers — more to read, more to trace, sometimes less efficient. That cost is worth paying only when it buys flexibility the design actually needs.
• Introduce a pattern when the need has emerged, not in anticipation of it. If a simpler solution might work, give it the chance. You reach for a pattern when you're sure it addresses a real problem you're hitting now — repeated change in one spot, an extension point you keep fighting — not a hypothetical future one.
• Falling back on a design principle (below) often dissolves the problem without any named pattern at all. If that happens, don't fight it.

So the honest answer to "which pattern should I use here?" is sometimes "none — here's the simpler structure." The Output shape section below encodes this — and the rule that every recommendation states its cost.

How to use this lens

When code structure is the question, work in this order: