Spring dependency injection (DI) and spring dependency di

Spring dependency injection (DI) and spring dependency di
1. Dependency Overview

A typical enterprise application is not composed of a single object (or bean in Spring ). Even the simplest application only works with a few objects to present the end user as a coherent application. From defining many independent bean definitions to fully-implemented applications, how can object collaboration be achieved in these applications.
For details about spring design patterns and applications, refer to my article spring common design patterns and applications.

Ii. Dependency Injection

Dependency injection (DI) is a process through which objects can be passed through the constructor parameters, factory method parameters or properties set after the object instance is constructed or returned to define their Dependencies from the factory method. Then, the container injects These dependencies when creating the bean. This process is basically the opposite, so it is called control inversion (IoC ), it uses the direct construction of classes or the service locator mode to control the instantiation or location of its own dependencies.
The code is clearer than the DI principle, and the decoupling is more effective when the object provides dependency. This object does not search for its dependency, and does not know the location or class of the dependency. Therefore, your classes become easier to test, especially when dependencies are on interfaces or abstract base classes, they allow the use of stubs or simulated implementations in unit tests.
DI has two major variants: constructor-based dependency injection and Setter-based dependency injection.

Iii. constructor-based dependency Injection

The constructor-based DI is completed by calling the constructor with multiple parameters through the container. Each parameter represents a dependency. It is almost equivalent to calling a factory method with specific parameters to construct the bean. in this discussion, the parameters are also treated as constructors and static factory methods. The following example shows the classes that can only be injected through constructor injection. Note that this class has nothing special about it. It is a POJO and does not rely on container-specific interfaces, base classes, or annotations.
 

public class SimpleMovieLister {     private MovieFinder movieFinder;     public SimpleMovieLister(MovieFinder movieFinder) {         this.movieFinder = movieFinder; } }

 

1. constructor Parameter Match

The constructor uses the parameter type for Parameter Parsing and matching. If there is no potential ambiguity in the constructor parameters defined by bean, the order in which the constructor parameters are defined in bean definition is the order in which these parameters are provided to the appropriate constructor during bean instantiation.

package x.y; public class Foo {     public Foo(Bar bar, Baz baz) {         // ...     } }

 
There is no potential ambiguity. Assume that Bar and Baz are not inherited. Therefore, you do not need to specify the constructor parameter indicators explicitly in the <constructor-arg> index, type, or type.
 

<beans>     <bean id="foo" class="x.y.Foo">         <constructor-arg ref="bar"/>         <constructor-arg ref="baz"/>     </bean>     <bean id="bar" class="x.y.Bar"/>     <bean id="baz" class="x.y.Baz"/> </beans>

 
In the previous scenario, if you explicitly specify the type of the constructor parameter using the type attribute, the container can use the type that matches the simple type.

<bean id="exampleBean" class="examples.ExampleBean">     <constructor-arg type="int" value="7500000"/>     <constructor-arg type="java.lang.String" value="42"/> </bean>

 
Use the index attribute to specify the index of the explicitly constructed function parameter.

<bean id="exampleBean" class="examples.ExampleBean">     <constructor-arg index="0" value="7500000"/>     <constructor-arg index="1" value="42"/> </bean>

You can also use the constructor parameter name to match

<bean id="exampleBean" class="examples.ExampleBean">     <constructor-arg name="years" value="7500000"/>     <constructor-arg name="ultimateAnswer" value="42"/> </bean>

 

2. Setter-Based Method

When you call a non-parameter constructor or a non-parameter static factory method to instantiate a bean, bean-based call of the Setter method is completed through bean call of the Setter method.

public class SimpleMovieLister {     private MovieFinder movieFinder;     public void setMovieFinder(MovieFinder movieFinder) {         this.movieFinder = movieFinder;     } }

 

The Spring team usually advocates constructor injection because it enables an application component to be implemented as an immutable object and ensures that the required dependencies are not null. In addition, constructor injection components always return to the client (CALL) code in the fully initialized state. As an example, a large number of constructor parameters are a bad smell of code, which means classes may have too many responsibilities and should be properly separated by better problem solving.
 
Setter injection should be mainly used for optional dependencies, which can be assigned reasonable default values in the class. Otherwise, the non-empty check must be executed anywhere the Code uses dependencies. The first advantage is that the setter method enables the objects of this class to be reconfigured or re-injected. Therefore, JMX MBean management is a compelling use case for setter injection.