Dependency Injection vs Service Locator Pattern
Fast recall
Quick revision
Core answer
context.getBean() to fetch them. DI is strongly preferred because dependencies are visible in the constructor signature, easy to mock, and don't create the hidden dependencies that make Service Locator an anti-pattern in modern Spring.Whether you grasp the push-vs-pull trade-off and why modern Spring treats Service Locator as an anti-pattern.
Thinking `applicationContext.getBean()` sprinkled through business logic is normal Spring usage rather than a hidden-dependency smell.
Point out that Service Locator hides what a class needs — you can't tell its dependencies from the signature, which kills testability and clarity.
Interview-ready guide
Interview answer
The key difference is push versus pull.
Dependency Injection pushes dependencies into your class from outside. Spring reads your constructor parameters and injects the matching beans. Service Locator pulls dependencies from a central registry.
Your class calls something like applicationContext dot getBean to fetch what it needs. DI is the modern, preferred approach, and here's why. With DI, dependencies are explicit in the constructor.
You look at it and immediately see the class needs a UserRepository and an EmailService. With Service Locator they're hidden in the implementation, so you can't tell what the class needs without reading every method. That hurts testability.
With DI I pass mock objects through the constructor in a unit test. With Service Locator I'd have to mock the entire ApplicationContext, which is far more work. Service Locator also couples your business logic to Spring's API, because getBean is everywhere.
With DI my service is just a plain Java class that Spring happens to manage. The point that stands out is the hidden dependency problem. When you can't see what a class needs from its signature, maintenance gets painful and refactors fail silently at runtime.
Dependency Injection vs Service Locator Pattern
Direct Answer
Dependency Injection pushes dependencies into a class from outside — the Spring container injects them through the constructor. The Service Locator pattern pulls dependencies from a central registry — the class calls something like context.getBean() to fetch them. DI is strongly preferred because dependencies are visible in the constructor signature, easy to mock, and don't create the hidden dependencies that make Service Locator an anti-pattern in modern Spring.
Common Mistakes & Pitfalls
- Treating getBean as normal: injecting ApplicationContext and calling getBean throughout your code looks flexible but defeats DI and creates untestable, tightly coupled code.
- Missing the hidden-dependency problem: a class with no constructor parameters but many getBean calls hides what it depends on — you must read every method to find out.
- Using Service Locator for lazy initialization: you don't need getBean to delay creation. Spring's
@Lazyannotation does that and keeps the dependency explicit.
Check your understanding
Answer these without looking back at the article.
- Why is Service Locator considered an anti-pattern?
- When is it acceptable to use ApplicationContext.getBean()?
- What is the Dependency Inversion Principle?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.