A Five-Question Checklist for Explaining Design Patterns

Start with a decision, not a diagram

An interview answer becomes useful when another engineer can see why a design exists and how to test it. Naming Strategy, Observer or Mediator is only a starting point. Use these five questions to turn vocabulary into a concrete argument.

1. What must always be true?

Write one invariant in ordinary language. For an order, it might be that a confirmed booking owns a valid reservation. For pricing, it might be that a discount never produces a negative total. A class diagram cannot compensate for an unclear rule.

2. What actually varies?

Distinguish interchangeable calculations from lifecycle-dependent behavior. Several shipping-price policies can be a Strategy problem. The legal operations on a dispatched order are a state-transition problem. If there are just two stable branches, a readable conditional may be sufficient.

3. Who owns the dependency?

Independent screens reacting to a reading are different from a workflow that must persist before billing. Put required ordering in an explicit owner rather than relying on subscribers happening to run in a convenient sequence. Explain which component chooses the next action and which component owns each local rule.

4. What happens when a boundary fails?

Walk through one thrown exception, a slow dependency and a duplicate request. A timeout is not evidence that the first attempt had no effect. State whether an operation can be retried safely, what identity identifies the same logical work, and how a user learns the eventual result.

5. What is the smallest design that meets the need?

Compare your proposal with a direct function call or a small application service. Extra indirection earns its place only if it makes a real variation or dependency easier to understand, test or change. Explain what evidence would make you simplify the design later.

A worked answer

Imagine a dashboard with a temperature chart and a logging panel. Both independently react to updates, so a subscription-based design is reasonable. Each screen owns its subscription lifetime. Now introduce a rule that a reading must be stored before an invoice is created. That dependency belongs in a workflow with an explicit failure policy; it should not be hidden in the relative registration order of two panels.

A strong answer describes both relationships and the point where they differ. It also names the tests: closing a screen removes its subscription; a failed persistence step prevents invoicing; retrying a completed operation does not create another invoice.

Practice

Apply the checklist to the Observer and Mediator workshop, then attempt the free design workbook. Write a short answer before drawing any classes.

For the worked Observer/Mediator case, apply these five prompts to the 8-question Observer, Mediator, Chain of Responsibility and Visitor lesson practice (Full Access). Explain the invariant, owner, failure boundary and simpler alternative before checking each answer. This practice covers Observer, Mediator, Chain of Responsibility and Visitor; it does not assess every design pattern mentioned in the checklist.

Further reading

• Erich Gamma interview: Design Principles from Design Patterns