Spring Core: IoC & DI

What is Spring Framework?

Spring is a Java application framework built around one core idea: your business classes should not be responsible for finding, constructing, or wiring together the other objects they depend on. Spring does that job — through a container that creates, configures, and connects your objects (called beans) based on configuration you provide via annotations or Java code.

Spring is not one library — it's a modular ecosystem. Spring Core (this page) is the foundation everything else builds on: the IoC container and dependency injection mechanism. On top of that sit Spring MVC (web layer), Spring Data (persistence), Spring Security (auth), and dozens more — each usable independently, all sharing the same underlying container and configuration model.

/*
 *  The Spring ecosystem, roughly:
 *
 *  Spring Core/Beans/Context  ← THIS PAGE — IoC container, DI, bean lifecycle
 *  Spring AOP                 ← cross-cutting concerns (logging, transactions, security)
 *  Spring MVC                 ← web layer: controllers, request mapping
 *  Spring Data                ← repositories, JPA/MongoDB/Redis integration
 *  Spring Security             ← authentication, authorisation
 *  Spring Boot                ← auto-configuration + embedded server + starters
 *                                (NOT a different framework — built ON TOP of all the above)
 */

What is Inversion of Control, and Why Does It Exist?

Inversion of Control (IoC) means an object no longer creates or looks up its own dependencies — a container creates them and hands them in. Dependency Injection (DI) is the specific technique Spring uses to achieve that: dependencies arrive via constructor, setter, or field, rather than the object instantiating them with new.

The problem this solves: when a class creates its own dependencies, it is permanently coupled to one concrete implementation. Swapping a real payment gateway for a test double means editing the class itself. Testing in isolation becomes impossible without a real database connection, a real HTTP client, a real everything. IoC inverts that: the class declares what it needs via its constructor signature, and remains ignorant of how that dependency gets built or which concrete implementation it actually receives.

// ❌ Without IoC — UserService is permanently coupled to UserRepositoryImpl
public class UserService {
    private final UserRepository userRepository;
    public UserService() {
        this.userRepository = new UserRepositoryImpl();  // hardcoded, untestable in isolation
    }
}

// ✅ With IoC — Spring builds and hands in whatever implements UserRepository
@Service
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {  // no @Autowired needed — single constructor (Spring 4.3+)
        this.userRepository = userRepository;
    }
}
// In tests: new UserService(mockRepository) — no Spring container required at all

Injection Types — and Why Constructor Wins

// ✅ Constructor injection — the only one to use for required dependencies
@Service
public class OrderService {
    private final OrderRepository orderRepository;
    private final PaymentService paymentService;

    public OrderService(OrderRepository orderRepository, PaymentService paymentService) {
        this.orderRepository = orderRepository;
        this.paymentService = paymentService;
    }
}

// ⚠️ Setter injection — only for genuinely OPTIONAL dependencies
@Service
public class NotificationService {
    private MetricsCollector metrics;  // app works fine if this is never set

    @Autowired(required = false)
    public void setMetrics(MetricsCollector metrics) { this.metrics = metrics; }
}

// ❌ Field injection — avoid in application code
@Service
public class BadExample {
    @Autowired
    private EmailService emailService;  // can't be final, can't construct without reflection,
                                            // dependency is invisible at the constructor
}

Declaring Beans

Stereotype annotations — component scanning

@Component   // generic — anything not fitting a more specific stereotype
@Service     // business logic layer — semantically the same as @Component, signals intent
@Repository  // data access layer — ALSO enables automatic exception translation
             // (JDBC/JPA exceptions become Spring's DataAccessException hierarchy)
@Controller  // MVC presentation layer, returns view names
@RestController  // = @Controller + @ResponseBody — returns response bodies directly (REST APIs)

Explicit @Bean declarations — for third-party classes you can't annotate

@Configuration
public class AppConfig {

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder.setConnectTimeout(Duration.ofSeconds(5)).build();
    }

    // Use @Bean specifically for classes you don't own — can't add @Component to a
    // third-party library's class. For your own classes, prefer stereotype annotations.
}

Resolving multiple implementations: @Primary and @Qualifier

public interface PaymentGateway { void charge(BigDecimal amount); }

@Service @Primary  // default winner when multiple PaymentGateway beans exist and no qualifier is given
class StripeGateway implements PaymentGateway { ... }

@Service
class PaypalGateway implements PaymentGateway { ... }

@Service
public class CheckoutService {
    private final PaymentGateway gateway;

    public CheckoutService(@Qualifier("paypalGateway") PaymentGateway gateway) {  // overrides @Primary explicitly
        this.gateway = gateway;
    }
}

Bean Lifecycle

A bean isn't just constructed once and forgotten — Spring runs it through distinct phases, and you can hook into the boundaries.

/*
 *  1. Constructor called (dependencies already resolved at this point)
 *  2. Dependencies injected (setter/field injection happens here, if used)
 *  3. @PostConstruct methods invoked — bean is fully wired, ready for setup logic
 *  4. Bean is in active use
 *  5. @PreDestroy methods invoked — container shutdown, last chance to clean up
 */

@Service
public class CacheWarmer {
    private final ProductRepository repo;
    private Map<Long, Product> cache;

    public CacheWarmer(ProductRepository repo) { this.repo = repo; }

    @PostConstruct
    void warmUp() {
        cache = repo.findAll().stream().collect(Collectors.toMap(Product::id, p -> p));
        // runs once, after construction AND dependency injection — repo is guaranteed non-null here
    }

    @PreDestroy
    void shutdown() {
        cache.clear();  // release resources before the container tears down
    }
}

// Alternative for classes you can't annotate (third-party, via @Bean):
@Bean(initMethod = "start", destroyMethod = "stop")
public SomeThirdPartyClient client() { return new SomeThirdPartyClient(); }

Bean Scopes

The scoped bean injection problem — and how to actually fix it

A singleton is created once. If you inject a prototype or request-scoped bean directly into a singleton's constructor, you get exactly one instance of it, frozen forever — defeating the entire purpose of the narrower scope.

// ❌ BROKEN: TaskProcessor is prototype, but injected once into a singleton
// — every call gets the SAME instance, not a fresh one
@Service  // singleton by default
public class JobRunner {
    private final TaskProcessor processor;  // resolved ONCE, at JobRunner's own construction
    public JobRunner(TaskProcessor processor) { this.processor = processor; }
}

// ✅ FIX 1: ObjectProvider — request a fresh instance on every call
@Service
public class JobRunner {
    private final ObjectProvider<TaskProcessor> processorProvider;
    public JobRunner(ObjectProvider<TaskProcessor> processorProvider) {
        this.processorProvider = processorProvider;
    }
    public void runJob() {
        TaskProcessor processor = processorProvider.getObject();  // fresh prototype instance, every call
        processor.execute();
    }
}

// ✅ FIX 2: scoped proxy — Spring injects a proxy that resolves the real
// instance from the current scope on every method call, transparently
@Component @Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class TaskProcessor { ... }
// Now direct constructor injection of TaskProcessor works correctly — the
// injected reference is a proxy, not the real bean, and delegates per-call.

ApplicationContext vs BeanFactory

BeanFactory is the root IoC container interface — lazy, minimal, rarely used directly today. ApplicationContext extends it with everything a real application needs: eager singleton instantiation by default, internationalisation support, event publishing, and AOP integration. In practice, you always work with ApplicationContext; BeanFactory is mostly of historical/interview interest.

// Spring Boot — ApplicationContext created and managed automatically
@SpringBootApplication  // = @Configuration + @EnableAutoConfiguration + @ComponentScan
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

// Without Spring Boot — rare today, mostly for understanding what Boot does for you
ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
UserService userService = ctx.getBean(UserService.class);

Publishing and listening to events

// Decouple "something happened" from "who reacts to it" — beans don't
// need direct references to each other to communicate
public record OrderPlacedEvent(Long orderId, BigDecimal total) {}

@Service
public class OrderService {
    private final ApplicationEventPublisher publisher;
    public OrderService(ApplicationEventPublisher publisher) { this.publisher = publisher; }

    public void placeOrder(Order order) {
        // ... save order ...
        publisher.publishEvent(new OrderPlacedEvent(order.id(), order.total()));
    }
}

@Component
public class OrderNotifier {
    @EventListener
    void onOrderPlaced(OrderPlacedEvent event) {
        // runs synchronously by default; add @Async to run on a separate thread
    }
}

Circular Dependencies

@Service
public class A { public A(B b) { } }

@Service
public class B { public B(A a) { } }  // A needs B, B needs A — circular

Conditional Beans and Profiles

// Only register this bean when the active profile matches
@Service @Profile("prod")
class SesEmailService implements EmailService { ... }

@Service @Profile("!prod")  // anything except prod — dev, test, local
class ConsoleEmailService implements EmailService { ... }

// Register a bean only if a property has a specific value (or is absent + default given)
@Service
@ConditionalOnProperty(name = "feature.new-checkout", havingValue = "true")
class NewCheckoutFlow { ... }

Testing: Plain Unit Tests vs Spring Context Tests

// ✅ FASTEST: plain unit test — no Spring involved at all, just Java + Mockito
// This is exactly what constructor injection enables and field injection prevents
@Test
void createUser_sendsWelcomeEmail() {
    UserRepository mockRepo  = mock(UserRepository.class);
    EmailService    mockEmail = mock(EmailService.class);
    UserService service = new UserService(mockRepo, mockEmail);  // no Spring container, milliseconds to run

    service.createUser(new User("a@b.com"));
    verify(mockEmail).sendWelcomeEmail("a@b.com");
}

// ⚠️ SLOWER: @SpringBootTest loads the full ApplicationContext — only for
// genuine integration tests that need real wiring, real config, real beans
@SpringBootTest
class UserServiceIntegrationTest {
    @Autowired private UserService userService;  // field injection is fine HERE — test code, not production code

    @MockitoBean  // replaces the real bean in the context with a mock (Spring Boot 3.4+ name; @MockBean on older versions)
    private EmailService emailService;
}

Interview Questions