在Spring中我们为什么要使用构造器的方式进行依赖注入？

背景

• 我们在使用Spring写web项目的时候，非常喜欢使用@Resource，@Autoweired注解。
• 我们也可以使用构造器的方式进行依赖注入。
• 也可以使用set方法进行依赖注入。
• 可是，我们有思考过究竟用哪种方式更好啊？Spring官方推荐使用构造器的方式进行依赖注入

过程

• spring的依赖注入，一般我们使用注解@Resource, @Autowired ， 但是也依然可以使用构造器的方式进行依赖注入，或者set方法依赖注入。
  @Autowired 加上构造器方法，方法体中的内容就是给属性进行赋值。 @Autowired 加上setXxx方法，方法体中的内容就是给属性赋值。

• 有这么多依赖注入方式，那我们应该选择哪个？

1. @Autowired @Resource 简单，简洁

2. 构造器在属性特别多的是，就显得很是臃肿，代码不美观。

3. set方法比较纯粹，但是没有@Autowire @Resource 简洁。

4. 如果我们在使用@Autowired 和 @Resource 这样的注解的时候，其实很容易在代码中写出了循环依赖的问题。 虽然spring框架本身解决了循环依赖的问题，启动项目不报错，但是如果某个方法调用了循环依赖对象的方法，方法中出现循环依赖，那么就是一个死循环方法执行？

5. 要这样思考：spring解决循环依赖，只是没有让项目报错，只是让对象之间在循环依赖的场景中生存。因此，我们的目的是：尽可能避免循环依赖这样的事情。

6. 构造器依赖注入：就能够提前暴露项目中的代码出现了循环依赖，我们应该去解决这个循环依赖的现象。

7. 如果考虑到构造器进行依赖注入的属性过多，而显得很臃肿的情况。

   ①我们应该去思考的问题是：类的职责是否单一。

   ②也就是： 我的一个类最多依赖注入：几个属性。

   ③但是，实际开发过程中， 由于业务复杂度的增加，往往导致一个类属性特别多。

• spring依赖注入的结论

1. 采用spring推荐做法，构造器依赖注入。

2. 考虑到代码臃肿，不美观的情况。我们采用lombok的注解即可，完美。

3. 理解到为什么自己要使用构造器进行依赖注入。提前避免出现循环依赖情况。

小结

• 构造器进行依赖注入。

• 提供了一个思路？

1. 我要用构造器进行依赖注入，然而它既带来的优点，也带来了缺点。
2. 然而，缺点，虽然没有本质解决它，但是采用了lombok这样的简化手段。因为lombok简化了代码，美化了编辑界面。

• 其他关于Spring的依赖注入的细节问题

1. 细节，有的时候，代码提示不能够自动注入。是因为这个接口可能有多个实现。
2. 采用@Qualifier的方式指定要哪个具体的对象。
3. 虽然接口有很多实现，但是采用了Conditional这样的注解，一般情况下，应用程序中也只有一个有效的实例对象。因此，使用自动注入也依然是合理的。