Pattern Selection
Select a pattern by the change it isolates and the contract it preserves. A pattern is a design option with costs, not an interview keyword that makes an implementation correct.
What you’ll understand
- Select a pattern by the change it isolates and the contract it preserves. A pattern is a design option with costs, not an interview keyword that makes an implementation correct.
- Practice explaining a design decision with an example and a boundary case.
Ask diagnostic questions
When a vendor uses incompatible units, consider Adapter. When the caller needs one simple use-case operation over several components, consider Facade. When an algorithm should be replaceable, consider Strategy. When behavior follows a lifecycle, consider State. These distinctions come from intent rather than similar-looking delegation code.
- What is stable for the caller?
- What varies independently?
- Who controls the collaborator’s lifetime?
Compare with the smallest alternative
A function parameter can be a strategy. A plain factory function may solve a construction problem without creator subclasses. A dictionary of transitions may be clearer than several tiny state classes. Explain why the additional structure pays for itself under the stated requirements.
- Estimate the number of real variations, not imagined ones.
- Explain what becomes harder after adopting the pattern.
- Avoid claiming a pattern guarantees performance or scalability.
Use an extension as evidence
Describe the next plausible change and show exactly which component would change. For a shipping adapter, a renamed vendor field should affect the adapter rather than checkout. For a new visitor operation, existing element classes should remain stable but a new element kind affects all visitors.
- Which edit demonstrates the benefit?
- Which edit exposes the tradeoff?
- When would you remove the abstraction again?