set⽅法注⼊和字段注⼊会间接违反单⼀职责原则。
因为在⼀个类依赖很多其他类的时候，如果使⽤构造⽅法注⼊就会发现构造⽅法的参数太多，这会让开发⼈员反思这个类真的需要这么多依赖吗？当前类是不是职责过多？
⽽使⽤字段注⼊时，就会把⼀些例如sonar的提⽰屏蔽掉，让开发⼈员误以为这样做没有问题
可以创建不可变类
在使⽤构造⽅法注⼊时因为构造⽅法是创建依赖对象的唯⼀⽅式，这⾮常有助于让我们创建不可变的对象。
想象⼀下创建⼀个bean之后你可以通过set⽅法随意修改此类的依赖，在出现问题时是很难定位的。
@Autowired的源码有⼀段注释如下：Fields are injected right after construction of a bean, before any config methods are invoked. Such a config field does not have to be public.
⼤意是使⽤@Autowired注解时，bean是在构造当前的bean之后，并且在任何的其他⽅法调⽤之前注⼊，因此⽆法设置成final类型的字段。
更明显的声明所有的依赖
使⽤构造⽅法注⼊，在使⽤这个类时就会暴露给使⽤者说我要依赖构造⽅法中的类。
但是使⽤字段注⼊时，使⽤者其实并不知道这个类依赖了哪些类，除⾮我到此类中查看这个类有多少个字段是有@Autowired注解。
不⽅便迁移
validation框架spring实现了DI（控制反转），但并⾮是DI本⾝；
使⽤构造⽅法注⼊时，除了在类上⾯有@Service、@Component等的注解，没有其他的Spring相关的更多的注解。
使⽤字段注⼊时，除了在类上⾯有@Service、@Component等的注解之外⼜使⽤了Spring的@Autowired注解，如果把此类迁移到其他没有spring的环境时是完成不了注⼊的。
不⽅便测试
在使⽤构造⽅法注⼊时，单元测试时开发⼈员可以直接传⼊⼀个mock的类或者其他的任何被测试类依赖的⼦类；
当然我们也可以使⽤set⽅式注⼊⼀个mock的类，但是如果代码修改了新增了⼀个依赖，那么我们很容易忘掉在测试代码中set新增的依赖，直到运⾏的时候我们才会看到可能有NPE异常爆出；但是构造⽅法就不必有这种烦恼，因为如果新增了⼀个依赖，测试⽅法会马上编译不通过。
使⽤字段注⼊，必须依赖Spring去帮助注⼊依赖的类
总结
通过构造⽅法注⼊bean是我们更容易创建不可变类，代码更健壮、更具有可测试性、更容易避免NPE。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。