为什么Spring不建议使用field方式注入

为什么Spring不建议使用field方式注入

前言

使用Spring框架最核心的两个功能就是IOC和AOP。IOC也就是控制反转,我们将类的实例化、依赖关系等都交由Spring来处理,以达到解耦合、利用复用、利于测试、设计出更优良程序的目的。而对用户来说,操作最对的便是注解。在Spring中提供了三类注解方式,下面我们就逐一分析。最后,你会发现,你最常用、看起来最方便的形式确实最不推荐的一种形式。

常见的注入方式

Field注入

@Controller
public class FooController {
  @Autowired
  // @Resource
  private FooService fooService;
}

此种注解方式,应用最广泛:

  • 注入简单,只需在字段上添加@Autowired或@Resource;
  • 减少大量冗余代码,美观;
  • 新增Field时不需要过多代码修改;

构造函数注入

@Controller
public class FooController {

  private final FooService fooService;
  private final FooService1 fooService1;

  @Autowired
  public FooController(FooService fooService,FooService1 fooService1) {
      this.fooService = fooService;
      this.fooService1 = fooService1;
  }


}

@Controller
public class FooController {

  private final FooService fooService;
  // 当只有一个参数时可不写@Autowired
  public FooController(FooService fooService) {
      this.fooService = fooService;
  }
}

Spring4.x推荐的注入方式。对比Field注入:

  • 代码臃肿
  • 新增Field修改麻烦
  • 当Field多余5个时不符合构造方法的基本规范,显得笨重、臃肿;

setter注入

@Controller
public class FooController {

  private FooService fooService;

  @Autowired
  public void setFooService(FooService fooService) {
      this.fooService = fooService;
  }
}

Spring3.x推荐的注入方式,但并没有被广泛应用,当初推荐的理由:

  • 解决了构造器注入的笨重;
  • 可以让类在之后重新配置或者重新注入。

为什么Spring4.x推荐构造函数注入

在上面的分析看来,构造函数注入好像并没有显现出来它的优势,但问什么Spring4.x会推翻之前推荐的setter注入,采用构造函数注入呢?官方的理由汇总如下:

  • 依赖不可变:加入了final来约束修饰Field,这条是很显然的;
  • 依赖不可为空:在实例化的时候会检查构造函数参数是否为空,如果为空(未找到改类型的实例对象)则会抛出异常。
  • 单一职责:当使用构造函数注入时,如果参数过多,你会发现当前类的职责过大,需要进行拆分。而使用Field注入时,你并不会意识到此问题。
  • 更利于单元测试:按照其他两种方式注入,当单元测试时需要初始化整个spring的环境,而采用构造方法注入时,只需要初始化需要的类即可,即可以直接实例化需要的类。
  • 避免IOC容器以外环境调用时潜在的NPE(空指针异常)。
  • 避免循环依赖。
  • 保证返回客户端(调用)的代码的时候是完全初始化的状态。

疑问

如果有大量依赖需要注入,怎么办?

如果有大量依赖需要注入说明该类的职责过于复杂,需要遵从单一性原则进行拆分;

其他注入方式是否合理?

存在即合理,根据具体情况可以采用最适合的方式。比如,可以同时使用@Qualifier来达到一些约束限定的目的。也可以使用setter注入和构造函数注入相结合的方式来进行注入。

参考文档


原文:为什么Spring不建议使用field方式注入 | 筱进GG的博客

image

2 个赞