Spring为什么建议使用构造器来注入？

原创于 2024-12-31 07:41:39 发布 · 840 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#spring #面试

java面试题专栏收录该内容

168 篇文章

订阅专栏

作者简介：大家好，我是码炫码哥，前中兴通讯、美团架构师，现任某互联网公司CTO，兼职码炫课堂主讲源码系列专题

代表作：《jdk源码&多线程&高并发》，《深入tomcat源码解析》，《深入netty源码解析》，《深入dubbo源码解析》，《深入springboot源码解析》，《深入spring源码解析》，《深入redis源码解析》等

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬。码炫课堂的个人空间-码炫码哥个人主页-面试，源码等

Spring 提供了三种依赖注入的方式：

基于字段的注入
基于 Setter 方法的注入
基于构造函数的注入

基于字段的注入

基于字段的注入就是直接在类的字段上注入所需的依赖，一般是使用 @Autowired、@Resource 来实现的。采用这种注入方式，Spring 容器在创建Bean时会自动寻找匹配的 Bean 并注入到被@Autowired所标记的字段中。

@Autowired  
private UserService userService;

这种注入的本质上是通过反射的方式直接注入到字段。它是我们日常开发中使用的最多也是最熟悉的一种注入方式，因为它使用方便而且简洁。但是，它也是 Spring 团队所不推荐的方式。主要原因有如下几个：

容易违背了单一职责原则：使用基于字段注入的方式，添加依赖非常简单，要使用一个接口直接添加依赖即可，哪怕我们添加 10个、20 个也不觉得有什么问题，这就会导致过度使用，再加上对依赖的隐蔽性，会导致一个类承担过多的职责，很容易违背了单一职责原则。
难以进行单元测试：由于与 Spring 容器强依赖，所以使得在不依赖Spring框架的情况下进行单元测试变得更加困难。
不支持不可变性：字段注入不支持 final 字段，这意味着无法创建不可变的bean。

基于 Setter 方法的注入

基于 Setter 方法的注入是通过类的 setter 方法来注入依赖，如下：

public class UserService {
    private ArticleService articleService;

    @Autowired
    public void setArticleService(ArticleService articleService) {
        this.articleService = articleService;
    }
}

注：在 Spring 4.3 及以后的版本中，setter 上面的 @Autowired 注解可以不写。

这种方式的优点在于它的灵活性，允许在对象创建后更改依赖，它对于那些不是必须的依赖或者可能在运行时更改的依赖特别有用。

但是它也存在过度使用的风险，导致一个类配置依赖过多，从而违背单一职责原则。

构造器注入

构造器注入通过类的构造函数来完成依赖注入的。

public class UserService {
    private ArticleService articleService;

    @Autowired
    public UserService(ArticleService articleService) {
        this.articleService = articleService;
    }
}

构造器注入是 Spring 所推荐的方式，主要原因有如下几个：

强依赖性：使用构造器注入时，所有的依赖都必须在对象创建时提供。这确保了依赖项不会被遗漏，从而防止了空指针异常和部分初始化的对象。
支持不可变性：只有使用构造器注入才能允许依赖被声明为 final。
避免循环依赖：使用构造器注入时，如果存在循环依赖，在 Spring 启动的时候就会抛出 BeanCurrentlyInCreationException，从根上杜绝循环依赖。因为循环一来本来就是一种不好的设计。
单一职责：在使用构造器注入时，我们会很容易发现参数是否过多，当参数过多时，就需要考虑这个类的职责是否过大，考虑拆分的问题。
提高类的可测试性：由于构造器注入可以直接在单元测试中通过构造器传递依赖项，使得单元测试更加容易。
降低容器耦合度：依赖注入的核心思想之一是受容器管理的类不应该去依赖容器所使用的依赖。换句话说，一个类应该只是一个普通的POJO，只要将其传递给所有必需的依赖项，它就可以独立地实例化。这样，我们可以在单元测试中实例化它，而无需启动IOC容器并单独进行测试。如果没有容器耦合，则可以将该类用作托管或非托管类，甚至可以切换到新的DI框架。