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

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

前言

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

常见的注入方式

Field注入

1. @Controller
   
2. publicclassFooController{
   
3.  @Autowired
   
4.  // @Resource
   
5.  privateFooService fooService;
   
6. }
   

此种注解方式，应用最广泛：

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

构造函数注入

1. @Controller
   
2. publicclassFooController{
   
3. 
   
4.  privatefinalFooService fooService;
   
5.  privatefinalFooService1 fooService1;
   
6. 
   
7.  @Autowired
   
8.  publicFooController(FooService fooService,FooService1 fooService1){
   
9.      this.fooService = fooService;
   
10.      this.fooService1 = fooService1;
    
11.  }
    
12. 
    
13. 
    
14. }
    

或

1. @Controller
   
2. publicclassFooController{
   
3. 
   
4.  privatefinalFooService fooService;
   
5.  // 当只有一个参数时可不写@Autowired
   
6.  publicFooController(FooService fooService){
   
7.      this.fooService = fooService;
   
8.  }
   
9. }
   

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

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

setter注入

1. @Controller
   
2. publicclassFooController{
   
3. 
   
4.  privateFooService fooService;
   
5. 
   
6.  @Autowired
   
7.  publicvoid setFooService(FooService fooService){
   
8.      this.fooService = fooService;
   
9.  }
   
10. }
    

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

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

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

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

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

疑问

如果有大量依赖需要注入，怎么办？

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

其他注入方式是否合理

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

Idea插件支持

Idea已经提供了相应的插件支持：