你可能使用了Spring最不推荐的注解方式

前些天新加入项目中的小伙儿写了一段代码，我看到之后，顿时以固有的经验来判断说：Spring的注解不能这样写，不够简洁云云。但本着对技术的钻研精神，还是深入分析比较了一下Spring的注解形式及优缺点。原来，大家最常用的注解方式不是最优的，而是最不推荐的。

前言

使用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注入和构造函数注入相结合的方式来进行注入。

其他

原文链接：https://www.choupangxia.com/topic/detail/84