Spring DI and SOLID Principles
Fast recall
Quick revision
Core answer
UserRepository interface, and Spring injects the concrete implementation at runtime. DI also supports Single Responsibility (classes focus on logic, not wiring) and the Open/Closed Principle (add new implementations without editing existing code).Whether you can connect a Spring feature to a design principle and name the specific SOLID letter DI implements.
Saying DI 'helps with SOLID' in general but being unable to name the Dependency Inversion Principle or explain it.
Explain DIP concretely — a service depends on a repository interface and Spring wires in the JPA implementation at runtime.
Interview-ready guide
Interview answer
Spring DI directly implements the Dependency Inversion Principle, the D in SOLID.
The principle says your high-level modules should depend on abstractions, not concrete implementations. Here's a concrete example. Say you have an OrderService that needs data access.
Without DI you'd write new JdbcOrderRepository, which tightly couples the service to that JDBC implementation. With Spring DI, OrderService depends on the OrderRepository interface, and Spring injects the real implementation at runtime, whether that's a JPA version, an in-memory version for tests, or something else. The service doesn't know or care which one it gets.
This also supports Single Responsibility, because the service focuses on business logic instead of constructing its dependencies. And it helps with the Open Closed Principle, because you can add a new repository implementation without touching the service. You just write a new class that implements the interface, and Spring wires it in.
A mistake Learners make is injecting concrete classes instead of interfaces, which keeps you coupled to one implementation and defeats the point. The key idea is that DI isn't only a Spring feature, it's how you put a fundamental design principle into practice, and naming the Dependency Inversion Principle shows you understand the architecture, not just the framework.
Spring DI and SOLID Principles
Direct Answer
Spring DI most directly implements the Dependency Inversion Principle (the D in SOLID), which says high-level modules should depend on abstractions, not concretions. Your service depends on the UserRepository interface, and Spring injects the concrete implementation at runtime. DI also supports Single Responsibility (classes focus on logic, not wiring) and the Open/Closed Principle (add new implementations without editing existing code).
Code Example
interface OrderRepository {
Optional<Order> findById(Long id);
void save(Order order);
}
@Repository
class JpaOrderRepository implements OrderRepository {
private final EntityManager em;
JpaOrderRepository(EntityManager em) { this.em = em; }
public Optional<Order> findById(Long id) { return Optional.ofNullable(em.find(Order.class, id)); }
public void save(Order order) { em.persist(order); }
}
@Repository
@Profile("test")
class InMemoryOrderRepository implements OrderRepository {
private final Map<Long, Order> store = new HashMap<>();
public Optional<Order> findById(Long id) { return Optional.ofNullable(store.get(id)); }
public void save(Order order) { store.put(order.id(), order); }
}
@Service
class OrderService {
private final OrderRepository repository; // interface, not a concrete class
OrderService(OrderRepository repository) { this.repository = repository; }
}
Common Mistakes & Pitfalls
- Depending on concrete classes: injecting
JpaUserRepositoryinstead of theUserRepositoryinterface keeps you coupled to one implementation and kills the testability DI is meant to give. - Mixing construction with logic: injecting some dependencies but newing others inside methods violates SRP and makes those objects impossible to mock.
- Not naming the principle: saying DI 'helps with SOLID' shows surface knowledge. The specific answer is the Dependency Inversion Principle — high-level modules depend on abstractions.
Check your understanding
Answer these without looking back at the article.
- What is the Dependency Inversion Principle?
- What are the five SOLID principles?
- How does coding to interfaces relate to DI?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.