Dependency Injection and Spring Beans

Your learning outcome for this lesson:

Explain the role of dependency injection and how Spring manages beans.

The Problem: Managing Object Dependencies

In object-oriented programming, classes often depend on other classes to do their work. For instance, a RateLimiterInterceptor will need a RateLimitingAlgorithm to check if a request should be allowed.

A straightforward but problematic way to handle this is to have the RateLimiterInterceptor create its own dependency:

// The 'traditional' way of managing dependencies
public class RateLimiterInterceptor {
    private RateLimitingAlgorithm algorithm;

    public RateLimiterInterceptor() {
        // The interceptor is responsible for creating its own dependency.
        this.algorithm = new TokenBucketAlgorithm(); 
    }

    // ... method to handle requests using the algorithm
}

This approach creates tight coupling. The RateLimiterInterceptor is permanently tied to the TokenBucketAlgorithm. What if you want to switch to a SlidingWindowAlgorithm? You'd have to change the RateLimiterInterceptor's code. This violates the principle of modularity and makes testing difficult.

Spring solves this with a powerful design principle: Inversion of Control (IoC).

1. Inversion of Control (IoC) and Dependency Injection (DI)

Inversion of Control means that you delegate the responsibility of creating and managing your objects (and their dependencies) to an external entity—in our case, the Spring framework. Your code no longer controls the creation of its dependencies; that control is inverted.

Dependency Injection (DI) is the specific programming pattern Spring uses to implement IoC. Instead of an object creating its dependencies, the dependencies are "injected" into it from an outside source.

To start, let's get a clear definition of these two related concepts.

This simple architectural shift has profound benefits:

• Decoupling: Components are no longer responsible for creating their dependencies, making them easier to swap, reconfigure, and reuse.
• Modularity: You can focus on a component's specific business logic.
• Testability: You can easily "inject" mock versions of dependencies during unit tests.

The diagram below illustrates this flow. A Controller doesn't create a NotificationService; it simply declares that it needs one, and the framework provides it.

2. The Spring IoC Container and Beans

So, if your objects aren't creating their dependencies, who is? This is the job of the Spring IoC Container.

The container is the heart of a Spring application. It's an environment that performs three main tasks:

1. Instantiates objects.
2. Configures these objects (e.g., injects their dependencies).
3. Manages their complete lifecycle (from creation to destruction).

The objects that the Spring IoC Container manages are called Spring Beans. A bean is simply a Plain Old Java Object (POJO) that you've handed over to Spring for management.

For a more detailed breakdown, the following article from Baeldung is an excellent reference.

3. Declaring and Injecting Beans in Practice

Now for the practical part: how do you tell Spring what to manage as a bean, and how do you get those beans where you need them?

There are two primary ways to declare a bean:

1. @Component and its specializations: Used to mark a class you've written, telling Spring's component scanner to pick it up and register it as a bean.
2. @Bean: Used inside a special @Configuration class to declare a bean from a method. This is perfect for when you don't control the source code (e.g., third-party libraries) or need custom instantiation logic.

The following video from Dan Vega provides a fantastic, code-driven walkthrough of both methods. It starts by demonstrating the problem of manual instantiation and then shows how Spring's DI solves it.

Stereotype Annotations

As you saw in the video, @Component is the general-purpose annotation. However, Spring provides more specific annotations to give your components semantic meaning. These are called stereotype annotations:

• @Service: For business logic classes (e.g., our future RateLimitingService).
• @Repository: For data access classes that interact with a database.
• @Controller / @RestController: For classes that handle web requests.

Under the hood, all these annotations are themselves annotated with @Component. Using the more specific ones helps organize your application and allows frameworks to apply special behaviors (e.g., exception translation for @Repository).

Injecting Dependencies: Constructor Injection

Once a bean is registered in the Spring container, you can inject it into another bean. While there are a few ways to do this (field, setter, constructor), constructor injection is the highly recommended approach.

@Service // This class is a bean
public class OrderService {

    private final PricingService pricingService; // The dependency

    // The dependency is injected through the constructor
    public OrderService(PricingService pricingService) {
        this.pricingService = pricingService;
    }

    public void processOrder() {
        // Use the injected service
        double price = pricingService.calculatePrice();
        // ...
    }
}

@Service // The dependency is also a bean
public class PricingService {
    public double calculatePrice() {
        // ... logic
        return 100.0;
    }
}

Why is constructor injection preferred?

• Immutability: You can declare your dependencies as final, ensuring they cannot be changed after the object is constructed.
• Clarity: A class's required dependencies are clearly stated in its constructor signature.
• Guaranteed State: The object is guaranteed to be in a complete, usable state upon creation, as it cannot be instantiated without its dependencies.

The Baeldung article you looked at earlier has excellent sections detailing the different injection types if you want to explore their trade-offs further. You can refer to sections 5, 6, and 7 of the resource "Inversion of Control and Dependency Injection with Spring".

Key Takeaways

• Inversion of Control (IoC) is a core principle where you delegate object creation and management to a framework.
• Dependency Injection (DI) is the pattern Spring uses to implement IoC, providing objects with their dependencies from an external source.
• The Spring IoC Container (or ApplicationContext) is the framework component that manages your objects.
• Objects managed by the container are called Spring Beans.
• You declare your own classes as beans using stereotype annotations like @Component, @Service, or @RestController.
• You declare beans from third-party code or with custom logic using the @Bean annotation inside a @Configuration class.
• Constructor injection is the recommended way to provide a bean with its dependencies.

Next Steps

You now have a solid theoretical and practical understanding of how Spring connects the different components of an application. This is the last piece of foundational knowledge we need before we can start building our API.

In the next lesson, we will use this knowledge to create our first REST API endpoint using @RestController and @RequestMapping. We will build a simple controller that uses an injected service, putting today's concepts directly into practice. This endpoint will be the target we will eventually protect with our rate limiter.