Inversion of Control (IoC) and Dependency Injection in Spring

Q: Inversion of Control (IoC) and Dependency Injection in Spring

**IoC** is the design principle where the **framework — not your code** — controls object creation and lifecycle. **Dependency Injection** is the mechanism Spring uses to implement IoC: dependencies are **provided to a class from the outside** rather than created internally with `new`. Spring's `ApplicationContext` is the **IoC container** — it reads `@Component` and `@Bean` declarations, instantiates beans, resolves their dependencies, and manages the full lifecycle. This decoupling is what makes Spring applications **testable**, **configurable per environment**, and **loosely coupled**. The interview-relevant distinction: **IoC is the principle** (Hollywood: 'don't call us, we'll call you'); **DI is one mechanism** to achieve it (Service Locator is another).

Intermediate·2 min read·

AmazonGoogleMicrosoftInfosysTCSNetflix

Fast recall

Quick revision

Core answer

IoC is the design principle where the framework — not your code — controls object creation and lifecycle. Dependency Injection is the mechanism Spring uses to implement IoC: dependencies are provided to a class from the outside rather than created internally with new. Spring's ApplicationContext is the IoC container — it reads @Component and @Bean declarations, instantiates beans, resolves their dependencies, and manages the full lifecycle. This decoupling is what makes Spring applications testable, configurable per environment, and loosely coupled. The interview-relevant distinction: IoC is the principle (Hollywood: 'don't call us, we'll call you'); DI is one mechanism to achieve it (Service Locator is another).

Interview-ready guide

Interview answer

Spring's whole model is built around one insight — the new keyword is a hard dependency. When OrderService does new StripeGateway() inside its constructor, those two classes are permanently coupled. IoC and Dependency Injection are Spring's solution.

Inversion of Control

The framework controls object creation and lifecycle — your class does not reach out and wire itself
Spring's ApplicationContext is the IoC container: it reads @Component and @Bean declarations, creates beans, resolves dependencies, and manages their lifecycle
The shift: you declare what you need, Spring decides which implementation to provide

Dependency Injection

DI is the specific mechanism — dependencies come in from outside the class instead of being created internally with new
Makes testing clean: new OrderService(mockGateway) in a unit test, StripeGateway in production — OrderService never changes
IoC and DI are not synonyms: IoC is the principle, DI is one mechanism. Service Locator is another

Constructor injection — the recommended style

Spring team's recommendation for mandatory dependencies: final fields, explicit constructor signature, testable without the container
Since Spring 4.3, a class with one constructor does not need @Autowired — Spring uses it automatically
Lombok's @RequiredArgsConstructor gives you zero-boilerplate injection

Why constructor over field

Constructor injection exposes circular dependencies at startup (BeanCurrentlyInCreationException)
Field injection hides them and produces partially-initialized proxy beans that fail only at runtime
Field injection cannot use final and cannot be unit tested without ReflectionTestUtils or a full Spring context

In modern Spring projects: constructor injection for mandatory deps, setter injection for optional ones, never field injection in production code.

03 · Deep dive