30.5.2. Dependency Injection (DI)

A type of IoC where dependencies are provided to a class instead of being created inside the class.

Dependency Injection (DI) is a specific method under the broader umbrella of Inversion of Control (IoC). The central idea of DI is that rather than a class creating its own dependencies (like objects it needs to function), those dependencies are provided from the outside. This means the framework or other code will handle the creation and passing of those dependencies into the class. By doing this, the class becomes less tightly coupled to its dependencies, which makes the class easier to test and maintain.

Think of a chef in a kitchen. Instead of the chef going to the grocery store to pick up ingredients (dependencies), a delivery service brings fresh ingredients directly to the kitchen. This way, the chef can focus on cooking (the main job) rather than sourcing the ingredients, which is handled by someone else. This separation simplifies the chef’s role and allows for flexibility in choosing different ingredients without changing the chef’s cooking methods.

• Constructor Injection • Setter Injection • Field Injection (via Annotations)

There are several common methods for implementing Dependency Injection, namely:

1. Constructor Injection: Dependencies are provided as parameters to the constructor of a class. This approach ensures that all required dependencies are available when the object is created, emphasizing immutability.
2. Setter Injection: In this method, dependencies are provided through setter methods after the object is constructed. This allows for optional dependencies but may lead to partially constructed objects if not all setters are called.
3. Field Injection: This uses annotations to inject dependencies directly into the fields of a class. It offers a concise way to declare dependencies but can obscure the flow of dependency management, particularly for new developers who may not immediately see where dependencies come from.

Imagine a construction project:

• Constructor Injection is like having a complete toolbox delivered before building starts. The builders have everything they need and can start right away without waiting for additional supplies.
• Setter Injection is like getting tools delivered gradually as the project progresses. Builders can start with basic tools and add more as needed, but they risk running into problems if not all tools are available at the right time.
• Field Injection is akin to having tools scattered all over the workspace, making it easy for builders to grab what they need instantly. However, it can be disorganized, and new builders might take longer to find everything they need.

@Component public class Car { @Autowired private Engine engine; }

In this example, we see how Dependency Injection is implemented in Java using annotations. The @Component annotation marks the Car class as a Spring-managed bean, while the @Autowired annotation on the engine field indicates that Spring should automatically inject an Engine object into this field when a Car object is created. This allows for the Car class to operate without needing to know how to create an Engine, thus promoting loose coupling between classes.

Think of this as an automated car manufacturing process. Instead of a worker manually assembling each part of the car (engine, body, wheels), an automated system recognizes what parts are needed and supplies them at the right time. Here, the 'worker' is the Spring Framework, which takes care of gathering the required parts (objects) for the assembly (the Car object) without the worker needing to understand where the parts come from.

--