1.4.1.1. Constructor-based Dependency Injection(基于构造函数的依赖注入) (Part I）

 Spring Framework Documentation (5.3.10)

Core	IoC Container, Events, Resources, i18n, Validation, Data Binding, Type Conversion, SpEL, AOP.

   Core Technologies

1. The IoC Container

1.1. Introduction to the Spring IoC Container and Beans（Spring IoC容器和bean简介）

1.2. Container Overview （容器概览）

1.3. Bean Overview （Bean概览）

1.4. Dependencies(依赖)

1.4.1. Dependency Injection(依赖注入)

1.4.1.1. Constructor-based Dependency Injection(基于构造函数的依赖注入) (Part I）

1.4.1.1. Constructor-based Dependency Injection(基于构造函数的依赖注入) (Part II）

1.4.1.2.Setter-based Dependency Injection(基于Setter的依赖注入)

1.4.1.3.Dependency Resolution Process(依赖解析过程)  

1.4.1.4. Examples of Dependency Injection(依赖注入示例)

1.4.2. Dependencies and Configuration in Detail(依赖与配置详细介绍)

1.4.3. Using depends-on(使用depends-on)

1.4.4. Lazy-initialized Beans(延迟初始化Bean)

1.4.5. Autowiring Collaborators(自动装配协作者)

1.4.6. Method Injection(方法注入)

1.4.6.1. Lookup Method Injection(查找方法注入)

1.4.6.2. Arbitrary Method Replacement(任意方法替换)

1.5. Bean Scopes（Bean作用域）

---

下载此文档精编完整版

No.	内容	下载地址	文档内容目录
1	中英双语精编版 第一部分	PDF下载	内容目录
2	中英双语精编版 第二部分	PDF下载	内容目录
3	中文精编版 第一部分	PDF下载	内容目录
4	中文精编版 第二部分	PDF下载	内容目录

更多章节内容，请点击查看：  Core Technologies

---

1.4.1.1. Constructor-based Dependency Injection(基于构造函数的依赖注入)

Constructor-based DI is accomplished by the container invoking a constructor with a number of arguments, each representing a dependency. Calling a static factory method with specific arguments to construct the bean is nearly equivalent, and this discussion treats arguments to a constructor and to a static factory method similarly. The following example shows a class that can only be dependency-injected with constructor injection:

基于构造函数的依赖注入是通过容器调用具有多个参数的构造函数来完成的，每个参数表示一个依赖项。调用带有特定参数的静态工厂方法来构造bean几乎是等效的，本讨论采用类似方式处理构造函数和静态工厂方法的参数。以下示例展示了一个类，该类只能通过构造函数注入方式进行依赖注入：

Java

public class SimpleMovieLister {

    // the SimpleMovieLister has a dependency on a MovieFinder
    private final MovieFinder movieFinder;

    // a constructor so that the Spring container can inject a MovieFinder
    public SimpleMovieLister(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }

    // business logic that actually uses the injected MovieFinder is omitted...
}

Kotlin

// a constructor so that the Spring container can inject a MovieFinder
class SimpleMovieLister(private val movieFinder: MovieFinder) {
    // business logic that actually uses the injected MovieFinder is omitted...
}

Notice that there is nothing special about this class. It is a POJO that has no dependencies on container specific interfaces, base classes, or annotations.

请注意，这个类没有什么特别之处。它是一个POJO，不依赖于特定于容器的接口、基类（base class）或注解（annotation）。

Constructor Argument Resolution(构造函数参数解析)

Constructor argument resolution matching occurs by using the argument’s type. If no potential ambiguity exists in the constructor arguments of a bean definition, the order in which the constructor arguments are defined in a bean definition is the order in which those arguments are supplied to the appropriate constructor when the bean is being instantiated. Consider the following class:

构造函数参数解析匹配（Constructor argument resolution matching）通过使用参数的类型（argument’s type）进行。如果bean定义的构造函数参数中不存在潜在的歧义，那么在bean定义中定义构造函数参数的顺序就是在实例化bean时将这些参数提供给相应构造函数的顺序。考虑下面的类：

Java

package x.y;

public class ThingOne {

    public ThingOne(ThingTwo thingTwo, ThingThree thingThree) {
        // ...
    }
}

Kotlin

package x.y

class ThingOne(thingTwo: ThingTwo, thingThree: ThingThree)

Assuming that the ThingTwo and ThingThree classes are not related by inheritance, no potential ambiguity exists. Thus, the following configuration works fine, and you do not need to specify the constructor argument indexes or types explicitly in the <constructor-arg/> element.

假设ThingTwo 和ThingThree 类没有继承关系，则不存在潜在的歧义。因此，以下配置工作正常，您不需要在 <constructor-arg/>元素中显式地指定构造函数参数索引（constructor argument index）或类型。

<beans>
    <bean id="beanOne" class="x.y.ThingOne">
        <constructor-arg ref="beanTwo"/>
        <constructor-arg ref="beanThree"/>
    </bean>

    <bean id="beanTwo" class="x.y.ThingTwo"/>

    <bean id="beanThree" class="x.y.ThingThree"/>
</beans>

When another bean is referenced, the type is known, and matching can occur (as was the case with the preceding example). When a simple type is used, such as <value>true</value>, Spring cannot determine the type of the value, and so cannot match by type without help. Consider the following class:

当引用另一个bean时，类型是已知的，并且可以进行匹配（如前一个示例所示）。使用简单类型时，例如 <value>true</value>，Spring无法确定值的类型，因此在没有帮助的情况下无法按类型进行匹配。考虑下面的类：

Java

package examples;

public class ExampleBean {

    // Number of years to calculate the Ultimate Answer
    private final int years;

    // The Answer to Life, the Universe, and Everything
    private final String ultimateAnswer;

    public ExampleBean(int years, String ultimateAnswer) {
        this.years = years;
        this.ultimateAnswer = ultimateAnswer;
    }
}

Kotlin

package examples

class ExampleBean(
    private val years: Int, // Number of years to calculate the Ultimate Answer
    private val ultimateAnswer: String// The Answer to Life, the Universe, and Everything
)