Drawbacks of overusing Factory
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
A factory has a cost: the reader must follow another method, registry, or creator hierarchy to discover what is built and why. It can also add types and configuration that provide no value when a dependency is simple and stable. I use a factory when concrete selection, complex setup, or lifecycle is a real responsibility. Otherwise a constructor or direct dependency injection is clearer. I do not justify that choice with a universal speed claim; object cost depends on the actual implementation, while the main trade-off here is design clarity and change ownership.
Drawbacks of overusing Factory
Direct Answer
Overusing factories adds indirection, extra types, configuration, and another place to trace failures. It can hide a simple concrete dependency behind an abstraction that never varies. Plain construction is often clearer for a stable local object; the reason is readability and ownership, not a guaranteed performance advantage.
Common Mistakes & Pitfalls
- Treating Factory as always better than
new. It's a trade-off;newis clearer for stable, simple objects. - Ignoring the debugging cost. 'What type is this?' answered with 'it depends on the factory' is a smell.
- Premature abstraction. Adding Factory 'in case we need flexibility later' violates YAGNI — refactor when pain is real.
- One product, full factory. A factory with a single implementation is over-engineering.
Check your understanding
Answer these without looking back at the article.
- How do you decide between using 'new' directly versus a Factory?
- Can Spring's dependency injection replace the need for Factory pattern in most cases?
- What signals tell you it's time to refactor to a Factory?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.