# 1.4 依赖
典型的企业应用程序不会只有一个对象（或Spring术语中的bean）。即使是最简单的应用程序也有一些对象一起工作，最终呈现给用户。
下一节将解释如何从定义一些独立的bean到一个真实的应用程序，在该应用程序中通过对象协作来实现一个目标。
## 1.4.1. 依赖注入
依赖项注入（DI）是指：对象仅仅通过构造函数参数、工厂方法的参数或从工厂方法构造,或返回对象实例后在其上设置属性来定义其依赖项（即它们使用的其他对象）。然后，容器在创建bean时注入这些依赖项。这个过程基本上和bean通过直接类的构造器或服务定位器来定位其依赖的过程是相反的（因此称为控制反转）。
使用DI，代码更干净，当对象具有依赖关系时，去耦更有效。对象不需要查找其依赖项，甚至不知道依赖项的位置或类。 因此，你的类变得更容易测试，特别是当依赖于接口或抽象基类时。（允许在单元测试中使用stub或mock实现）
DI有两个主要的方式：基于构造函数的依赖注入和基于setter的依赖注入。
**基于构造函数的依赖注入**
基于构造函数的DI是通过容器调用带有多个参数的构造函数来实现的，每个参数表示一个依赖项。这个和调用带有特定参数的静态工厂方法来构造bean几乎是等效的，这里将会对构造函数和静态工厂方法的参数做相似的处理。下面的示例显示了一个只能通过构造函数注入依赖项的类：
```
public class SimpleMovieLister {
// the SimpleMovieLister has a dependency on a MovieFinder
private 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...
}
```
注意这个类没有什么特别的。它是一个POJO，不依赖于特定于容器的接口、基类或注解。
**构造函数参数的解析**
一般通过参数的类型来进行构造函数参数的解析匹配。如果bean定义的构造函数参数中没有潜在的歧义，那么在bean定义中定义构造函数参数的顺序就是在bean被实例化时，这些参数被提供给适当的构造函数的顺序。可以看下面的类：
```
package x.y;
public class ThingOne {
public ThingOne(ThingTwo thingTwo, ThingThree thingThree) {
// ...
}
}
```
假设ThingTwo和ThingThree类与继承无关，则不存在潜在的歧义。因此，以下配置工作正常，你不需要在< constructor-arg/>元素中显式指定构造函数参数索引或类型。
```
```
当引用另一个bean时，如果类型是已知的，可以通过类型进行匹配（前面的例子就是这样）。当使用简单类型时，例如\true\，Spring无法确定值的类型，因此在没有帮助的情况下无法按类型匹配。考虑以下情况：
```
package examples;
public class ExampleBean {
// Number of years to calculate the Ultimate Answer
private int years;
// The Answer to Life, the Universe, and Everything
private String ultimateAnswer;
public ExampleBean(int years, String ultimateAnswer) {
this.years = years;
this.ultimateAnswer = ultimateAnswer;
}
}
```
**构造函数类型匹配**
在前面的场景中，如果使用type属性显式指定构造函数参数的类型，则容器可以使用与简单类型匹配的类型。如下示例所示：
```
```
**构造函数索引**
你也可以使用index属性来显示的指定构造函数参数的位置，如下所示：
```
```
除了解决多个简单值的不确定性之外，指定索引还可以解决构造函数有两个相同类型参数的不确定性。
```
注意：index是从0开始的。
```
**构造函数名字匹配**
你也可以使用构造函数的参数名字来指定，如下所示：
```
```
请记住，要使用这项功能，必须在启用调试标志的情况下编译代码，以便Spring可以从构造函数中查找参数名。
如果无法或不希望使用调试标志编译代码，可以使用@ConstructorProperties JDK注解显式命名构造函数参数。然后示例类必须如下所示：
```
package examples;
public class ExampleBean {
// Fields omitted
@ConstructorProperties({"years", "ultimateAnswer"})
public ExampleBean(int years, String ultimateAnswer) {
this.years = years;
this.ultimateAnswer = ultimateAnswer;
}
}
```
**基于Setter的注入依赖**
基于Setter的DI是由容器在调用无参数构造函数或无参数静态工厂方法实例化bean之后调用bean上的setter方法来完成的。
下面的示例显示了一个类，该类只能通过使用纯setter注入来注入依赖项。这个类是传统的Java。它是一个POJO，不依赖于特定于容器的接口、基类或注解。
```
public class SimpleMovieLister {
// the SimpleMovieLister has a dependency on the MovieFinder
private MovieFinder movieFinder;
// a setter method so that the Spring container can inject a MovieFinder
public void setMovieFinder(MovieFinder movieFinder) {
this.movieFinder = movieFinder;
}
// business logic that actually uses the injected MovieFinder is omitted...
}
```
ApplicationContext支持它所管理的bean的基于构造函数和基于setter的DI。在通过构造函数方法注入了一些依赖项之后，仍然可以使用基于setter的DI。 所有的依赖都会被转化成为BeanDefinition，它会与PropertyEditor实例一起使用，将属性从一种格式转换为另一种格式。 然而，大多数Spring用户并不直接使用这些类（即代码编程方式），而是使用XML bean定义、注解的组件（即用@Component、@Controller等来注解的类），或基于Java的@Configuration注解中的@Bean方法。然后，这些定义会在内部转换为BeanDefinition实例，并被用于Spring IOC容器中。
> 构造函数还是setter形式的注入？
>
> 由于你可以混合使用基于构造函数和基于setter的DI，所以对于强制依赖项使用构造函数，对于可选依赖项使用setter方法或配置方法是一个很好的实践经验。 注意，可以使用setter方法上的@Required注解使属性成为必需的依赖项；但是，最好使用构造函数注入并在程序中做相应的验证。
>
> Spring团队通常提倡构造函数注入，因为它允许你将应用程序组件实现为不可变的对象，并确保所需的依赖项不为空。 此外，构造函数注入的组件总是以完全初始化的状态返回到客户端（调用）代码。另一点需要注意的是，大量的构造函数参数是一种糟糕的代码体验，这意味着类可能做了太多的事情，应该重构以做适当的分离。
>
> Setter注入应该主要用于可在类内分配合理默认值的可选依赖项。否则，在代码使用依赖项的任何地方都必须执行非空检查。 Setter注入的一个好处是Setter方法使该类的对象能够在以后重新配置或重新注入。因此，通过JMX MBeans进行管理是Setter注入的一个成功的用例。
>
> 对特定类使用最有意义的DI样式。有时，在处理没有源代码的第三方类时，只有一种选择。例如，如果第三方类不公开任何setter方法，那么构造函数注入可能是DI的唯一可用形式。
**依赖解析流程**
容器按如下流程处理Bean的依赖解析：
* ApplicationContext被创建和实例化出来，它包含了所有bean的配置元数据。这些配置元数据可以通过XML、Java代码或注解来指定。
* 对于每个bean，其依赖项都以属性、构造函数参数或静态工厂方法的参数的形式表示。当bean实际创建时，这些依赖项会提供给bean。
* 每个属性或构造函数参数都是要设置的值的实际定义，或者是对容器中另一个bean的引用。
* 作为值的每个属性或构造函数参数都将从其指定的格式转换为该属性或构造函数参数的实际类型。默认情况下，Spring可以将以字符串格式提供的值转换为所有内置类型，如int、long、String、boolean等。
Spring容器在创建容器时会验证每个bean的配置。但是，在bean实际创建之前，不会设置bean的属性。当创建容器时，单实例并设置为预实例化（默认方式）的bean会被创建。作用域被设置为bean作用域。否则，只有在请求bean时才创建它。创建bean可能会导致创建bean图，因为bean的依赖项及其依赖项的依赖项（等等）会被创建和分配。
请注意，这些依赖项之间的解析不匹配可能会很晚出现，也就是说，在第一次创建受影响的bean时。
> 循环依赖
>
> 如果主要使用构造函数注入，则可能创建循环依赖的场景。
>
> 例如：类A通过构造函数注入需要类B的实例，类B通过构造函数注入需要类A的实例。如果为要相互注入的类A和类B配置bean，那么SpringIOC容器在运行时检测到这个循环引用，会抛出BeanCurrentlyInCreationException。
>
> 一种可能的解决方案是编辑一些类的源代码，这些类由setter而不是构造函数配置。或者，避免构造函数注入，只使用setter注入。换句话说，尽管不建议这样做，但是可以使用setter注入配置循环依赖项。
>
> 与典型情况（没有循环依赖性）不同，bean a和bean b之间的循环依赖强制将其中一个bean注入另一个bean，然后完全初始化自己（经典的鸡和蛋场景）。
一般来说，你可以相信Spring会做正确的事。它在容器加载时检测配置问题，例如不存在的bean和循环依赖项的引用。
Spring在实际创建bean时设置属性并尽可能晚地解析依赖项。这意味着，如果在创建对象或其依赖项时出现问题，那么之前正确加载的Spring容器稍后可能在请求对象时生成异常，例如：bean由于缺少或无效的属性而引发异常。
对于这样的配置问题，这种潜在的延迟可见性是ApplicationContext实现默认情况下预实例化singleton bean的原因。
在实际需要使用这些bean之前，你需要花费一些前期时间和内存来创建它们，并在创建ApplicationContext时发现配置问题，而不是稍后。
你仍然可以重写这个默认行为，以便单例bean可以延迟初始化，而不是预先实例化。
如果不存在循环依赖关系，当一个或多个协作bean被注入依赖bean时，每个协作bean在被注入依赖bean之前都被完全配置。这意味着，如果bean a依赖于bean b，那么在bean a上调用setter方法之前，spring ioc容器会完全配置bean b。
换句话说，bean被实例化（即使它不是预实例化的singleton），它的依赖被设置，并且调用相关的生命周期方法（例如configured init方法或InitializingBean回调方法）。
**依赖注入的例子**
下面的示例是基于XML的配置元数据使用基于setter的DI。如下所示：
```
, \, \,和 \ 分别被用来设置Java Collection类型List, Set, Map，和 Properties 类型的属性和参数。 下面是个例子：
```
administrator@example.org
support@example.org
development@example.org
a list element followed by a reference
just some string