2. Spring Core: IoC, DI, Beans, and Scopes

Spring Code Examples

Constructor Injection

@Service
public class OrderService {
    private final PaymentClient paymentClient;
    private final OrderRepository orderRepository;

    public OrderService(PaymentClient paymentClient,
                        OrderRepository orderRepository) {
        this.paymentClient = paymentClient;
        this.orderRepository = orderRepository;
    }

    public void placeOrder(Order order) {
        paymentClient.charge(order.total());
        orderRepository.save(order);
    }
}
  

Bean Lifecycle Hooks

@Component
public class CacheWarmup {
    @PostConstruct
    public void init() {
        System.out.println("Load cache after dependencies are injected");
    }

    @PreDestroy
    public void shutdown() {
        System.out.println("Flush metrics before bean is destroyed");
    }
}
  

Interview Scenario Practice

Scenario 1: Required Dependencies

Scenario: A service cannot work without its repository and payment client.

Strong answer: Prefer constructor injection. Required dependencies become visible in the constructor, can be marked final, and fail fast if missing.

Why it works: Constructor injection improves testability and makes the class contract obvious.

Common mistake: Using field injection everywhere because it looks shorter. It hides required dependencies and makes unit tests clumsier.

Scenario 2: Cache Warmup

Scenario: You need to load reference data after Spring has injected all dependencies.

Strong answer: Use @PostConstruct for initialization that needs injected collaborators, or a dedicated startup runner for larger boot workflows.

Why it works: The bean is already constructed and dependencies are available.

Common mistake: Doing heavy dependency-based work inside the constructor before Spring has fully wired the object.

Scenario 3: User Data in Singleton Bean

Scenario: A singleton-scoped service stores per-request user information in a field.

Strong answer: Avoid mutable request-specific state in singleton beans. Keep state local to methods, use request scope where appropriate, or pass context explicitly.

Why it works: Singleton beans are shared, so mutable fields can leak values between requests and threads.

Common mistake: Assuming a Spring singleton means one instance per user. It means one instance per Spring container.