Why this matters

Design interviews (whether framed as "Low-Level Design" or as a broader system design round touching architecture — see the companion HLD & LLD and System Design books) frequently reward recognizing which pattern's problem shape matches what's being asked, without over-fitting a pattern that only superficially resembles the situation. This closing chapter is a decision framework for exactly that recognition step, built from the problem-first discipline this entire book has repeated.

A decision framework, not a lookup table

[SENIOR INSIGHT] The wrong way to prepare for this is memorizing "if the interviewer says X, use pattern Y" — that produces exactly the pattern-fever failure mode from Chapter 13, applied under interview pressure. The right way is to keep asking the same handful of diagnostic questions this book has used throughout, in order:

1. Is this about how something gets created? → creational patterns (Chapters 3–4).

   • One type, varies by subclass/parameter → Factory Method.
   • Multiple related types that must stay consistent as a family → Abstract Factory.
   • Complex, many-optional-parameter construction → Builder.
   • Exactly one instance needed application-wide → Singleton (and immediately note the DI alternative, per Chapter 4 — interviewers experienced with this pattern's downsides notice when a candidate reaches for it uncritically).
   • Cloning an expensive-to-construct object → Prototype.

2. Is this about how things are composed/related? → structural patterns (Chapters 5–7).

   • Incompatible interfaces need to work together → Adapter.
   • A complex subsystem needs a simple entry point → Facade.
   • Behavior needs to combine in multiple combinations at runtime → Decorator.
   • Access to an object needs controlling (lazy-load, protect, remote, cache) → Proxy.
   • The domain is a tree, and leaf/group should be treated uniformly → Composite.
   • Two+ independent axes of variation would otherwise multiply a hierarchy → Bridge.
   • Enormous object counts need shared, immutable state to control memory → Flyweight.

3. Is this about how things communicate/share responsibility? → behavioral patterns (Chapters 8–12).

   • An algorithm needs to vary independently, swappable at runtime → Strategy.
   • Several algorithms share a sequence, varying in specific steps → Template Method.
   • One object's change needs to notify an open-ended set of others → Observer.
   • Many objects have tangled many-to-many interactions → Mediator.
   • An action needs to be queued, logged, or undone → Command (± Memento if the undo isn't self-reversible).
   • Behavior depends entirely on current state, with invalid transitions to prevent → State.
   • A request should be handled by one of several handlers in sequence → Chain of Responsibility.
   • A custom collection needs traversal without exposing its structure → Iterator.
   • New operations need to be added across a stable family of types → Visitor.

4. Is this about the whole application's structure? → architectural patterns (Chapters 15–17), reserved for system-design-scale questions rather than a single-class design prompt.

Worked example: applying the framework live

[IN PRACTICE] Suppose an interviewer asks: "Design a system for applying discounts to an order, where the discount rules change frequently and marketing wants to A/B test different rule combinations."

A strong candidate's reasoning, out loud:

• "This is about an algorithm (the discount calculation) varying independently of the code that applies it, and it needs to be swappable — that's Strategy." (Question 3, first bullet.)
• "Since marketing wants to test combinations of rules, not just switch between single rules, I should check whether these compose — if a customer could get a loyalty discount and a seasonal discount stacked together, that's actually closer to Decorator's combinability than a single Strategy pick." (Recognizing Decorator's shape, Chapter 6.)
• "I don't see a need for Abstract Factory here — there's no family-of-related-objects consistency requirement, just swappable/combinable discount logic. I'll avoid introducing it." (Explicitly ruling out an over-fit, echoing Chapter 13.)

This is the entire value of the framework: it's not about landing on the "right" pattern immediately, it's about narrating the diagnostic process — which is exactly what the OOP book's Chapter 18 identified as the strongest signal in an interview, applied here specifically to pattern selection.

Handling the "no pattern fits cleanly" case

[SENIOR INSIGHT] Sometimes the honest answer is that no catalogued pattern fits the problem particularly well — and saying so, then designing directly from principles (SOLID, the four pillars) is a stronger answer than forcing a pattern to fit. Interviewers experienced with candidates who've recently studied a patterns book specifically watch for this: someone who reaches for the nearest plausible-sounding pattern regardless of fit reveals shallower understanding than someone willing to say "I don't think a named pattern is the right frame here, let me just design this directly."

Common mistakes

1. Pattern-matching on surface-level keywords ("the interviewer said 'notify,' so it must be Observer") instead of checking the actual shape of the problem against the diagnostic questions above.
2. Naming a pattern without being able to justify why its specific trade-offs fit this specific problem — a strong answer states the trade-off being accepted (e.g., "Visitor makes new operations cheap but new types expensive — I'm betting the type set here is stable"), not just the pattern's name.
3. Forcing a single pattern onto a problem that actually needs two combined (as in the discount example, which blends Strategy's swappability with Decorator's combinability) — real problems often don't map onto exactly one catalog entry.
4. Refusing to say "no pattern fits well here" when that's genuinely the case, instead contorting the design to justify a named pattern that doesn't really apply.

Discussion / interview questions

(Fittingly, this chapter's own questions are about the recognition process itself.)

1. "Walk me through how you'd decide which design pattern fits a new problem, without just pattern-matching on surface keywords." Strong answer: Describes the tiered diagnostic approach from this chapter — first the category (creation/composition/communication/whole-application), then the specific shape within that category — rather than jumping to a name based on a keyword match.

2. "Can you think of a problem where two patterns' shapes both partially apply, and how you'd handle that?" Strong answer: Uses an example like the discount-rules scenario (Strategy for swappability, Decorator for combinability) and explains combining or choosing between them based on which specific requirement (swap vs. combine) is actually being asked for.

3. "What would you say if you couldn't identify a named pattern that cleanly fit an interview design problem?" Strong answer: Say so directly, then design from underlying principles (SOLID, the four pillars) rather than forcing a mismatched pattern — frames this as a stronger answer than false-fitting, not a failure.

4. "How would you avoid 'pattern fever' while still demonstrating your knowledge of patterns in an interview?" Strong answer: State the problem first, explicitly name why a pattern's specific trade-off fits (not just its name), and be willing to say a pattern doesn't apply when it doesn't — demonstrating judgment, which interviewers weigh more heavily than pattern-name recall.

Chapter summary / cheat sheet

• Use a tiered diagnostic (creation → composition → communication → whole-application), not keyword pattern-matching, to identify which pattern's problem shape fits.
• Narrate the diagnostic process out loud — this is the actual signal interviewers are evaluating, more than landing on the "correct" pattern immediately.
• Real problems sometimes blend two patterns' shapes (e.g., Strategy + Decorator) — recognize and combine deliberately rather than forcing a single fit.
• When no pattern cleanly applies, say so and design from first principles (SOLID, the OOP pillars) — this is a stronger answer than a forced, unjustified pattern.
• The single discipline repeated in every chapter of this book — state the real, current problem before naming the pattern — is exactly what an interview is testing for, under time pressure.

---

End of Book

"Patterns of Good Design: A Practical Guide to Design Patterns" — 18 chapters, complete.

Next book in the suggested reading order: Operating System.