When should you NOT use a design pattern?
Quick Answer
Don't add a pattern for a problem you don't have yet. Patterns trade simplicity for flexibility; if the flexibility isn't needed, you've just added indirection, more files and a steeper learning curve. Reach for a pattern when a real, recurring pain appears — not because the codebase “should” have one.
I don't use a pattern until I actually feel the pain it solves. Every pattern buys flexibility at the cost of indirection and more moving parts, and if you don't need that flexibility you've made the code harder to read for no benefit. The classic examples are a generic repository over EF when you'll only ever have one database, or a strategy hierarchy with exactly one implementation added “for the future”. My approach is to write the straightforward version and refactor to a pattern when a third similar case appears or a test gets awkward. Patterns are a vocabulary for problems you have, not a checklist.
Signs a pattern is premature:
- A generic
Repository<T>over EF Core when you have one database and no plans to change. - A Factory that only ever creates one type.
- An Abstract Factory / Strategy hierarchy with a single implementation “for future flexibility”.
- Interfaces on everything, including internal classes only used in one place, purely for symmetry.
- MediatR / CQRS on a small CRUD service.
The healthier path: write the simple version, and refactor to a pattern when the third similar case shows up (rule of three) or a test becomes hard to write. Patterns are a shared vocabulary for solutions to recurring problems — applying them speculatively is how codebases become mazes.