依赖注入

IoC/DI 概念：2. IoC 控制反转
Spring官方文档：依赖注入

采用DI原则，代码会更干净，当对象被提供其依赖关系时，解耦会更有效。对象不会查找其依赖关系，也不知道依赖关系的位置或类别。因此，你的类变得更容易测试，特别是当依赖关系是在接口或抽象基类上时，这允许在单元测试中使用存根或模拟实现。

依赖注入方式

一、传递数据的方式

向类中传递输的方式一共有2种：

• 普通方法（ set 方法 ）：setter 注入
• 构造方法： 构造器注入

二、注入数据类型

依赖注入描述了在容器中建立了 bean 与 bean 之间依赖关系的过程，注入数据的类型有两类：

• 引用类型
• 简单类型（基本数据类型与String）

三、依赖注入的方式

• Setter 注入
  • 简单类型
  • 引用类型
• 构造器注入
  • 简单类型
  • 引用类型

依赖注入方式选择

1. 强制依赖使用构造器注入，使用 setter 注入有概率不进行注入导致 null 对象出现
2. 可选依赖使用 setter 进行注入，灵活性强
3. Spring 框架倡导使用构造器，第三方框架内部大多数采用构造器注入的形式进行数据初始化，相对严谨
4. 如果有必要，可以两者同时使用，使用构造器注入完成强制依赖的注入，使用 setter 注入完成可选依赖的注入
5. 实际开发过程中还要具体情况具体分析，如果受控对象没有提供 setter 方法就必须使用构造器注入
6. 自己开发的模块推荐使用 setter 注入

▶

关于注入方式

由于你可以混合使用基于构造函数和基于 setter 的 依赖注入方式，所以选择一个很好的经验是：对强制依赖使用构造函数，对可选依赖使用setter方法或配置方法。请注意，在setter方法上使用@Autowired注解可以使属性成为必须的依赖关系；然而，带有参数的程序化验证的构造函数注入更可取。

Spring团队通常提倡构造函数注入，因为它可以让你将应用组件实现为不可变的对象，并确保所需的依赖关系不为空。此外，构造函数注入的组件总是以完全初始化的状态返回给客户端（调用）代码。顺便提一下，大量的构造函数参数是一种不好的代码气味，意味着该类可能有太多的责任，应该重构以更好地解决适当的分离问题。

Setter 注入主要应该只用于在类中可以分配合理默认值的可选依赖。否则，必须在代码使用该依赖关系的所有地方进行非空值检查。设置器注入的一个好处是，设置器方法使该类的对象可以在以后进行重新配置或重新注入。因此，通过JMX MBeans进行管理是setter注入的一个引人注目的用例。

对于一个特定的类，使用最合理的DI风格。有时，在处理你没有源代码的第三方类时，会为你做出选择。例如，如果一个第三方类没有暴露任何setter方法，那么构造函数注入可能是唯一可用的注入形式。