Design Patterns interview question · Most asked
When should you NOT use a design pattern?
Summary
When the problem it solves isn't present yet: one implementation, no variation, or simple code that's easy to change later. Apply YAGNI and the rule of three, prefer language features (functions, named arguments, generators), and add the pattern when the variation becomes real.
Longer Answer
Each pattern adds indirection that readers must follow. A strategy interface with one implementation, a factory that only calls new, or a builder for a two-field object costs more than it saves. Refactoring toward a pattern later, with tests in place, is cheap when the need is real.
Key Points
- No problem, no pattern.
- YAGNI and the rule of three.
- Language features often replace patterns.
- Refactor toward patterns when variation appears.
Deep dive: Design Patterns, Explained Simply: Anti-Patterns and Over-Engineering
Explanation
What interviewers look for
Judgement and concrete over-engineering examples.
Follow-up questions
- Give an example where you removed a pattern.
More most-asked Design Patterns questions
- What problem does the Builder pattern solve? Show an example.
- Explain the SOLID principles.
- What is a design pattern, and why are they useful?
- What is the difference between dependency inversion, dependency injection and inversion of control?
- Why is composition often preferred over inheritance?
- What is dependency injection, and what forms does it take?
- Explain the Factory Method pattern and how it differs from a simple factory.
- How do you implement a Singleton, and why is it often considered an anti-pattern?