【Spring】浅谈spring为什么推荐使用构造器注入

一、前言

​ Spring框架对Java开发的重要性不言而喻,其核心特性就是IOC(Inversion of Control, 控制反转)和AOP,平时使用最多的就是其中的IOC,我们通过将组件交由Spring的IOC容器管理,将对象的依赖关系由Spring控制,避免硬编码所造成的过度程序耦合。前几天的时候,笔者的同事问我为什么要使用构造器的注入方式,我回答说因为Spring文档推荐这种,而说不出为什么 T^T,后面抽时间了解了一下,下面就是笔者要讨论的就是其注入方式。

二、常见的三种注入方式

​ 笔者为了方便起见就只是用注解的方式注入(现在也很少使用xml了吧,(~ ̄▽ ̄)~)

2.1 field注入

@Controller
public class FooController {
  @Autowired
  //@Inject
  private FooService fooService;
  
  //简单的使用例子,下同
  public List<Foo> listFoo() {
      return fooService.list();
  }
}

这种注入方式应该是笔者目前为止开发中见到的最常见的注入方式。原因很简单:

  1. 注入方式非常简单:加入要注入的字段,附上@Autowired,即可完成。
  2. 使得整体代码简洁明了,看起来美观大方。

2.2 构造器注入

@Controller
public class FooController {
  
  private final FooService fooService;
  
  @Autowired
  public FooController(FooService fooService) {
      this.fooService = fooService;
  }
  
  //使用方式上同,略
}

​ 在Spring4.x版本中推荐的注入方式就是这种,相较于上面的field注入方式而言,就显得有点难看,特别是当注入的依赖很多(5个以上)的时候,就会明显的发现代码显得很臃肿。对于从field注入转过来+有强迫症的园友 来说,简直可以说是石乐志  (`Д´*)9。对于这一点我们后面再来讨论,别急。

2.3 setter注入

@Controller
public class FooController {
  
  private FooService fooService;
  
  //使用方式上同,略
  @Autowired
  public void setFooService(FooService fooService) {
      this.fooService = fooService;
  }
}

​ 在Spring3.x刚推出的时候,推荐使用注入的就是这种,笔者现在也基本没看到过这种注解方式,写起来麻烦,当初推荐Spring自然也有他的道理,这里我们引用一下Spring当时的原话:

The Spring team generally advocates setter injection, because large numbers of constructor arguments can get unwieldy, especially when properties are optional. Setter methods also make objects of that class amenable to reconfiguration or re-injection later. Management through JMX MBeans is a compelling use case. Some purists favor constructor-based injection. Supplying all object dependencies means that the object is always returned to client (calling) code in a totally initialized state. The disadvantage is that the object becomes less amenable to reconfiguration and re-injection.

​ 咳咳,简单的翻译一下就是:构造器注入参数太多了,显得很笨重,另外setter的方式能用让类在之后重新配置或者重新注入

​ 那么后面为什么又换成构造器注入了呢?(喂喂喂,Spring你前一大版本还贬低构造器注入,后面就立刻捧人家了不好吧,不过能用于承认自己的错误,才是真正令人称赞的地方吧 (๑•̀ㅂ•́)و✧)

三、构造器注入的好处

​ 先来看看Spring在文档里怎么说:

The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state.

​ 咳咳,再来简单的翻译一下:这个构造器注入的方式啊,能够保证注入的组件不可变,并且确保需要的依赖不为空。此外,构造器注入的依赖总是能够在返回客户端(组件)代码的时候保证完全初始化的状态

下面来简单的解释一下:

  • 依赖不可变:其实说的就是final关键字,这里不再多解释了。不明白的园友可以回去看看Java语法。
  • 依赖不为空(省去了我们对其检查):当要实例化FooController的时候,由于自己实现了有参数的构造函数,所以不会调用默认构造函数,那么就需要Spring容器传入所需要的参数,所以就两种情况:1、有该类型的参数->传入,OK 。2:无该类型的参数->报错。所以保证不会为空,Spring总不至于传一个null进去吧 :-( 
  • 完全初始化的状态:这个可以跟上面的依赖不为空结合起来,向构造器传参之前,要确保注入的内容不为空,那么肯定要调用依赖组件的构造方法完成实例化。而在Java类加载实例化的过程中,构造方法是最后一步(之前如果有父类先初始化父类,然后自己的成员变量,最后才是构造方法,这里不详细展开。)。所以返回来的都是初始化之后的状态。

等等,比较完了setter注入与构造器注入的优缺点,你还没用说使用field注入与构造器的比较呢!那么我们再回头看一看使用最多的field注入方式:

//承接上面field注入的代码,假如客户端代码使用下面的调用(或者再Junit测试中使用)
//这里只是模拟一下,正常来说我们只会暴露接口给客户端,不会暴露实现。
FooController fooController = new FooController();
fooController.listFoo(); // -> NullPointerException

如果使用field注入,缺点显而易见,对于IOC容器以外的环境,除了使用反射来提供它需要的依赖之外,无法复用该实现类。而且将一直是个潜在的隐患,因为你不调用将一直无法发现NPE的存在。

还值得一提另外一点是:使用field注入可能会导致循环依赖,即A里面注入B,B里面又注入A:

public class A {
    @Autowired
    private B b;
}

public class B {
    @Autowired
    private A a;
}

如果使用构造器注入能够避免上述循环依赖这种情况

四、答疑

​ 好了,相信已经园友们知道了构造器注入的好处,那么回到了在前面提到的问题:

Q1:跟3.x里说的一样,我要是有大量的依赖要注入,构造方法不会显得很臃肿吗?

对于这个问题,说明你的类当中有太多的责任,那么你要好好想一想是不是自己违反了类的单一性职责原则,从而导致有这么多的依赖要注入。

Q2:是不是其他的注入方式都不适合用了呢?

当然不是,存在即是合理!setter的方式既然一开始被Spring推荐肯定是有它的道理,像之前提到的setter的方式能用让类在之后重新配置或者重新注入,就是其优点之一。除此之外,如果一个依赖有多种实现方式,我们可以使用@Qualifier,在构造方法里选择对应的名字注入,也可以使用field或者setter的方式来手动配置要注入的实现。

五、总结

​ 使用构造器注入的好处:

  1. 保证依赖不可变(final关键字)
  2. 保证依赖不为空(省去了我们对其检查)
  3. 保证返回客户端(调用)的代码的时候是完全初始化的状态
  4. 避免了循环依赖
  5. 提升了代码的可复用性

另外,当有一个依赖有多个实现的使用,推荐使用field注入或者setter注入的方式来指定注入的类型。这是spring官方博客对setter注入方式和构造器注入的比较。谢谢各位园友观看,如果有描述不对的地方欢迎指正,与大家共同进步!

参考链接:

https://spring.io/blog/2007/07/11/setter-injection-versus-constructor-injection-and-the-use-of-required/

http://vojtechruzicka.com/field-dependency-injection-considered-harmful/

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏美团技术团队

Spring MVC注解故障追踪记

Spring MVC是美团点评很多团队使用的Web框架。在基于Spring MVC的项目里,注解的使用几乎遍布在项目中的各个模块,有Java提供的注解,如:@O...

4237
来自专栏携程技术中心

干货 | JAVA反序列化安全实例解析

作者简介 迟长峰,携程技术中心信息安全部应用安全工程师。 什么是序列化 序列化 (Serialization)是指将对象的状态信息转换为可以存储或传输的形式的过...

35510
来自专栏Java3y

Spring IOC知识点一网打尽!

1888
来自专栏编舟记

R3 Corda 和 springboot 集成

因为Corda内置的Corda Webserver已经被标记成弃用了,一般不再提供支持;再者,springboot的生态明显占优。

2522
来自专栏MelonTeam专栏

浅析Binder机制

一个老生常谈的话题,但也是在Android学习过程中一定会遇到的一个主题。结合自己的学习历程分享一下我对Binder架构的基本理解吧。 刚开始学习的时候,并没...

26110
来自专栏竹清助手

浅谈Linux磁盘修复e2fsck命令

检查 /dev/mapper/VolGroup00-LogVol02 是否有问题,如发现问题便自动修复:

3162
来自专栏猿人谷

程序员需要知道的8个Linux命令

每个程序员,在职业生涯的某个时刻,总会发现自己需要知道一些Linux方面的知识。我并不是说你应该成为一个Linux专家,我的意思是,当面对linux命令行任务时...

1795
来自专栏java、Spring、技术分享

记一次unable to create new native thread错误处理过程

unable to create new native thread,看到这里,首先想到的是让运维搞一份线上的线程堆栈(可能通过jstack命令搞定的)。...

1.1K1
来自专栏ImportSource

刨根问底synchronized | 锁系列-Java中的锁

铺垫 在Java SE 1.5之前,多线程并发中,synchronized一直都是一个元老级关键字,而且给人的一贯印象就是一个比较重的锁。 为此,在Java ...

5045
来自专栏Java Web

Java 面试知识点解析(七)——Web篇

在遨游了一番 Java Web 的世界之后,发现了自己的一些缺失,所以就着一篇深度好文:知名互联网公司校招 Java 开发岗面试知识点解析 ,来好好的对 Jav...

37614

扫码关注云+社区

领取腾讯云代金券