Constructor Injection with @Autowired

What is Dependency Injection?

Before we look at Spring's annotations, let's solidify the concept of Dependency Injection itself. In any non-trivial application, objects collaborate to get work done. This means one object needs a reference to another.

The naive approach is for an object to create its own dependencies:

public class UserService {
    // Tightly coupled dependency creation
    private UserRepository userRepository = new UserRepository(); 

    public void findUser(long id) {
        // ... uses userRepository
    }
}

This creates a tight coupling between UserService and the concrete UserRepository class. It makes the code rigid, difficult to test (you can't easily substitute UserRepository with a mock version), and hard to manage.

Dependency Injection inverts this. Instead of creating its own dependencies, an object declares what it needs, and an external entity (the Spring IoC container) "injects" those dependencies into it.

To see this principle in action without the complexity of Spring, let's watch a short segment of a video.

As the video demonstrates, passing dependencies through the constructor is a robust way to ensure an object is always in a valid, usable state upon creation.

Dependency Injection Methods in Spring

Spring provides three primary ways to perform dependency injection, all of which typically use the @Autowired annotation to signal to the container that a dependency needs to be supplied.

1. Constructor Injection: Dependencies are provided as parameters to the class's constructor. This is the recommended method.
2. Setter Injection: Dependencies are provided through public setter methods. This is generally used for optional dependencies.
3. Field Injection: Dependencies are injected directly into the class fields. This is discouraged as it makes testing more difficult and hides dependencies from the outside world.

Given your background in system design, the benefits of making dependencies explicit and ensuring object immutability will be clear. Constructor injection is the only method that robustly supports these principles.

Implementing Constructor Injection

Now, let's apply this to a Spring context. Imagine we have a UserService that depends on a UserRepository. Both are defined as Spring beans.

@Service // This is a Spring bean
public class UserService {

    private final UserRepository userRepository; // The dependency

    // Spring will see this constructor and look for a bean of type UserRepository
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // ... methods that use userRepository
}

@Repository // This is also a Spring bean
public class UserRepository {
    // ... data access logic
}

When Spring creates the UserService bean, it inspects its constructor. It sees a required parameter of type UserRepository. It then looks in its container for a bean that matches this type. Finding the UserRepository bean, it passes that instance into the constructor, and the UserService is born fully formed and ready to use.

The Role of @Autowired

You will often see @Autowired on the constructor:

@Service
public class UserService {
    private final UserRepository userRepository;

    @Autowired // Explicitly marks the constructor for injection
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

However, as the official Spring documentation states, this is often optional.

Key Rule: As of Spring 4.3, if a class has only one constructor, you do not need to annotate it with @Autowired. Spring will automatically use that constructor for dependency injection. If you have multiple constructors, you must use @Autowired to tell Spring which one to use.

Since it is a best practice for your beans to have only one constructor for injecting mandatory dependencies, you will often find that you don't need to write @Autowired at all.

How Does It Work Internally?

Your preference for understanding the "why" behind framework features is valuable. Spring's "magic" is just well-written code, often using a powerful Java feature called Reflection.

Why Constructor Injection is a Best Practice

We've established that constructor injection is the recommended approach. Let's dive into the specific design and engineering reasons why this is the case. These principles are universal and align with robust system design practices you're likely familiar with from other ecosystems.

To summarize the key advantages:

• Immutability: Dependencies can be declared as final, guaranteeing they are assigned only once during construction. This is crucial for building thread-safe and reliable components.
• Explicit Dependencies: A class's contract clearly states what it needs to function. An object cannot be created in an incomplete state, which helps prevent NullPointerExceptions at runtime.
• Improved Testability: It's trivial to instantiate a class in a unit test and pass it mock implementations of its dependencies. This decouples your tests from the Spring framework.
• Avoids Circular Dependencies: If ServiceA needs ServiceB and ServiceB needs ServiceA, constructor injection will cause the application startup to fail with a clear error. Other injection types can mask this problem, leading to a StackOverflowError at runtime.
• Code Quality Signal: A constructor with a large number of arguments (e.g., > 5) is a strong indicator that the class may be taking on too many responsibilities and should be refactored.

A Brief Look at Ambiguity

A natural question arises: what happens if the container has multiple beans that satisfy a dependency? For example, what if we have a Computer interface, and two beans that implement it: Laptop and Desktop?

public interface Computer {
    void compile();
}

@Component
public class Laptop implements Computer { ... }

@Component
public class Desktop implements Computer { ... }

@Service
public class Developer {
    private final Computer computer;

    // Which bean gets injected here? Laptop or Desktop?
    public Developer(Computer computer) {
        this.computer = computer;
    }
}

If you run this, Spring will throw an exception at startup, telling you it found two eligible beans and doesn't know which one to choose. Spring requires you to resolve this ambiguity. We will cover this in detail later in the course, but it's good to be aware of the solutions.

Conclusion

In this lesson, we completed our initial tour of Spring's core dependency management. We now understand not just how Spring creates beans, but also how it wires them together to form a functioning application.

Here are the key takeaways:

• Dependency Injection (DI) is a design pattern where an object's dependencies are provided to it by an external entity, rather than the object creating them itself. This promotes loose coupling.
• Spring supports constructor, setter, and field injection, but constructor injection is the highly recommended best practice.
• With constructor injection, dependencies are passed as parameters to the constructor, allowing them to be marked as final for immutability.
• The @Autowired annotation on a constructor is optional if it's the only constructor in the class.
• Constructor injection improves code quality by making dependencies explicit and mandatory, enhancing testability, and helping to identify design issues like circular dependencies or violations of the Single Responsibility Principle.

We've now seen how to let Spring automatically discover our beans (@Component) and automatically wire them together (constructor injection). In the next lesson, we will explore another way to define beans: explicitly, using Java-based configuration with @Configuration and @Bean. This method is particularly useful when you need to create beans from classes you don't own, such as those from a third-party library.