Spring 官方为什么建议构造器注入？

前言
本章的内容主要是想探讨我们在进行 Spring 开发过程当中，关于依赖注入的几个知识点。感兴趣的读者可以先看下以下问题：

• @Autowired，@Resource，@Inject 三个注解的区别
• 当你在使用@Autowired时，是否有出现过Field injection is not recommended的警告？你知道这是为什么吗？

• Spring 依赖注入有哪几种方式？官方是怎么建议使用的呢？

@Autowired，@Resource，@Inject 三个注解的区别

@Autowired

public interface Svc {
    void sayHello();
}
@Service
public class SvcA implements Svc {

    @Override
    public void sayHello() {
        System.out.println("hello, this is service A");
    }

}
@Service
public class SvcB implements Svc {
    @Override
    public void sayHello() {
        System.out.println("hello, this is service B");
    }

}
@Service
public class SvcC implements Svc {

    @Override
    public void sayHello() {
        System.out.println("hello, this is service C");
    }
}

@SpringBootTest
public class SimpleTest {

    @Autowired
    // @Qualifier("svcA")
    Svc svc;

    @Test
    void rc() {
        Assertions.assertNotNull(svc);
        svc.sayHello();
    }

}

Guice 是 google 开源的轻量级 DI 框架

@Resource

Field injection is not recommended Inspection info: Spring Team Recommends: "Always use constructor based dependency injection in your beans. Always use assertions for mandatory dependencies

不建议使用基于 field 的注入方式。Spring 开发团队建议：在你的Spring Bean 永远使用基于constructor 的方式进行依赖注入。对于必须的依赖，永远使用断言来确认。

@Service
public class HelpService {
    @Autowired
    @Qualifier("svcB")
    private Svc svc;

    public void sayHello() {
        svc.sayHello();
    }
}
public interface Svc {
    void sayHello();
}
@Service
public class SvcB implements Svc {
    @Override
    public void sayHello() {
        System.out.println("hello, this is service B");
    }
}

@Service
public class HelpService {
    private final Svc svc;
    @Autowired
    public HelpService(@Qualifier("svcB") Svc svc) {
        // Assert.notNull(svc, "svc must not be null");
        this.svc = svc;
    }
    public void sayHello() {
        svc.sayHello();
    }
}

• 基于 field 注入（属性注入）
• 基于 setter 注入
• 基于 constructor 注入（构造器注入）

1. 基于 field 注入

@Autowired
private Svc svc;

2. 基于 setter 方法注入

通过对应变量的setXXX()方法以及在方法上面使用注解，来完成依赖注入。比如：

private Helper helper;
@Autowired
public void setHelper(Helper helper) {
    this.helper = helper;
}

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

3. 基于 constructor 注入

将各个必需的依赖全部放在带有注解构造方法的参数中，并在构造方法中完成对应变量的初始化，这种方式，就是基于构造方法的注入。比如：

private final Svc svc;
    
@Autowired
public HelpService(@Qualifier("svcB") Svc svc) {
    this.svc = svc;
}

在 Spring 4.3 及以后的版本中，如果这个类只有一个构造方法，那么这个构造方法上面也可以不写 @Autowired 注解。

基于 field 注入的好处

基于 field 注入的坏处

成也萧何败也萧何

• 容易违背了单一职责原则 使用这种基于 field 注入的方式，添加依赖是很简单的，就算你的类中有十几个依赖你可能都觉得没有什么问题，普通的开发者很可能会无意识地给一个类添加很多的依赖。但是当使用构造器方式注入，到了某个特定的点，构造器中的参数变得太多以至于很明显地发现 something is wrong。拥有太多的依赖通常意味着你的类要承担更多的责任，明显违背了单一职责原则（SRP：Single responsibility principle）。
• 依赖注入与容器本身耦合

  依赖注入框架的核心思想之一就是受容器管理的类不应该去依赖容器所使用的依赖。换句话说，这个类应该是一个简单的 POJO(Plain Ordinary Java Object)能够被单独实例化并且你也能为它提供它所需的依赖。

  这个问题具体可以表现在：
• 你的类不能绕过反射（例如单元测试的时候）进行实例化，必须通过依赖容器才能实例化，这更像是集成测试
• 你的类和依赖容器强耦合，不能在容器外使用
• 不能使用属性注入的方式构建不可变对象(final 修饰的变量)

Spring 开发团队的建议

Since you can mix constructor-based and setter-based DI, it is a good rule of thumb to use constructors for mandatory dependencies and setter methods or configuration methods for optional dependencies.

• 强制依赖就用构造器方式
• 可选、可变的依赖就用 setter 注入

  当然你可以在同一个类中使用这两种方法。构造器注入更适合强制性的注入旨在不变性，Setter 注入更适合可变性的注入。

让我们看看 Spring 这样推荐的理由，首先是基于构造方法注入，

而对于基于 setter 的注入，他们是这么说的：

基于 setter 的注入，则只应该被用于注入非必需的依赖，同时在类中应该对这个依赖提供一个合理的默认值。如果使用 setter 注入必需的依赖，那么将会有过多的 null 检查充斥在代码中。使用 setter 注入的一个优点是，这个依赖可以很方便的被改变或者重新注入。 

小结

参考

转自：Richard_Yi
来源：https://juejin.cn/post/6844904056230690824

PS：如果觉得我的分享不错，欢迎大家随手点赞、在看。
（完）




加我"微信" 获取一份 最新Java面试题资料
请备注：666，不然不通过～

最近好文

1、Spring Boot 实现扫码登录，这种方式太香了！！
2、SpringSecurity + JWT 实现单点登录
3、基于 Vue+Spring 前后端分离管理系统ELAdmin
4、Spring Boot 接入支付宝完整流程实战
5、Spring Boot 实现多图片上传并回显，涨姿势了～


最近面试BAT，整理一份面试资料《Java面试BAT通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式：关注公众号并回复 java 领取，更多内容陆续奉上。
明天见(｡･ω･｡)ﾉ♡