【Spring】基于field、set方法、构造方法注入

● 基于field方式
  ○ 注入形式：通过反射的方式直接注入到field
  ○ 优点：
    ■ 注入方式简单
    ■ 类可以专注于业务，而不被依赖注入所污染
  ○ 缺点：
    ■ 违背了单一原则，大批量的注入，不容易突出这个类的主要责任，导致这个类很臃肿
    ■ 依赖注入与容器本身耦合（依赖注入框架的核心思想之一就是受容器管理的类不应该去依赖容器所使用的依赖。换句话说，这个类应该是一个简单的POJO(Plain Ordinary Java Object)能够被单独实例化并且你也能为它提供它所需的依赖。）
      ● 你的类和依赖容器强耦合，不能在容器外使用
      ● 你的类不能绕过反射（例如单元测试的时候）进行实例化，必须通过依赖容器才能实例化，这更像是集成测试
    ■ 不能使用属性注入的方式构建不可变对象(final 修饰的变量)
● 基于set方法
  ○ 注入形式：通过对应变量的setXXX()方法以及在方法上面使用@Autowired注解（在 Spring 4.3 及以后的版本中，setter 上面的 @Autowired 注解是可以不写的），来完成依赖注入
  ○ 建议： setter 的注入，则只应该被用于注入非必需的依赖，同时在类中应该对这个依赖提供一个合理的默认值。如果使用 setter 注入必需的依赖，那么将会有过多的 null 检查充斥在代码中。使用 setter 注入的一个优点是，这个依赖可以很方便的被改变或者重新注入 
● 基于构造方法
  ○ 注入形式：各个必须的依赖全部放在带有@Autowired注解（在 Spring 4.3 及以后的版本中，如果这个类只有一个构造方法，那么这个构造方法上面也可以不写 @Autowired 注解。）构造方法的参数中，并在构造方法中完成对应变量的初始化
  ○ 建议：将依赖注入到一个不可变的变量中 (注：final 修饰的变量) ，另一方面也可以保证这些变量的值不会是 null 。此外，经过构造方法完成依赖注入的组件 (注：比如各个 service)，在被调用时可以保证它们都完全准备好了 。与此同时，从代码质量的角度来看，一个巨大的构造方法通常代表着出现了代码异味，这个类可能承担了过多的责任 。