IDEA 警告 Field injection is not recommended

发表于 更新于 分类于 Waline： 阅读次数：

前些天在开发过程中，发现 IDEA 在一个 @Autowired 注解上打了一个警告，内容是 Field injection is not recommended。多年面向 Spring 开发的经验告诉我，使用 @Autowired 注解进行依赖注入，肯定是没有问题的。但是我的代码洁癖不允许我这么不明不白的留一个警告在这里。所以，带着我的洁癖，和我的好奇心，我开始研究起了这个警告。

警告信息

这个警告，和警告的处理建议，在 IDEA 中是这么写的：

Warning Message

翻译过来是这个意思：

不建议直接在字段上进行依赖注入。
Spring 开发团队建议：在 Java Bean 中永远使用构造方法进行依赖注入。对于必须的依赖，永远使用断言来确认。

修改代码

既然 IDE 给了警告，那就先着手修改。一开始，代码是这样子的：

1
2
3
4
public class AClass{
    @Autowired
    private DependencyClass aDependency;
}

根据提示，我将代码修改成了这样子：

1
2
3
4
5
6
7
public class AClass {
    private final DependencyClass aDependency;

    public AClass(DependencyClass aDependency) {
        this.aDependency = aDependency;
    }
}

然后警告就消失了，同时运行没有问题，说明这个修改是可行的。

另外，如果你的项目中引入了 Lombok，那么代码甚至可以精简成这样子：

1
2
3
4
5
// 该注解指示Lombok为所有没被初始化过的final的变量创建构造方法
@RequiredArgsConstructor
public class AClass {
    private final DependencyClass aDependency;
}

但是，光是改好代码还远远不够，我需要知道，为什么 Spring 团队会提出这一项要求，以及，直接使用 @Autowired 进行依赖注入有什么问题。

依赖注入的类型

经过我的了解，Spring 有三种依赖注入的类型。

基于 field 的注入

所谓基于 field 的注入，就是在变量上使用 @Autowired 注解进行依赖注入。这是我们最熟悉的一种方式，同时，也正是 Spring 团队所不推荐的方式。它用起来就像这样：

1
2
@Autowired
private DependencyClass aDependency;

基于 setter 方法的注入

通过 setter() 方法，以及在方法上加入 @Autowired 注解，来完成的依赖注入，就是基于 setter 方法的注入。它用起来就像这样：

1
2
3
4
5
6
private DependencyClass aDependency;

@Autowired
public void setADependency(DependencyClass aDependency) {
    this.aDependency = aDependency;
}

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

基于构造方法的注入

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

1
2
3
4
5
6
7
8
9
10
11
public class AClass {
    // 这里 final 修饰符并不是必须的，但是我喜欢这么做
    // 因为这样不仅可以在代码上防止 aDependency 被修改
    // 在语义上也可以表明 aDependency 是不应该被修改的
    private final DependencyClass aDependency;

    @Autowired
    public AClass(DependencyClass aDependency) {
        this.aDependency = aDependency;
    }
}

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

基于 field 的注入有什么问题

基于 field 的注入，虽然不是绝对禁止使用，但是它可能会带来一些隐含的问题。比如，在这篇博客中，作者给出了这样的一个代码：

1
2
3
4
5
6
7
8
@Autowired
private User user;

private String school;

public UserAccountServiceImpl(){
    this.school = user.getSchool();
}

初看起来好像没有什么问题，User 类会被作为一个依赖被注入到当前类中，同时这个类的 school 属性将在初始化时通过 user.getSchool() 方法来获得值。但是，这个代码在运行时，却会抛出如下的异常：

1
Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name '...' defined in file [....class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [...]: Constructor threw exception; nested exception is java.lang.NullPointerException

即，在执行 UserAccountServiceImpl() 这个构造方法时出现了 NPE。

出现这个问题的原因是，Java 在初始化一个类时，是按照静态变量或静态语句块 –> 实例变量或初始化语句块 –> 构造方法 -> @Autowired 的顺序 [^1]，那么显而易见，在执行这个类的构造方法时，user 对象尚未被注入，它的值还是 null，从而产生了 NPE。

此外，在代码质量方面，因为基于 field 的注入用起来实在是太方便了，增加一个依赖只需要声明一个变量，然后给它加上 @Autowired 注解，就可以了。而这份便利，有可能会导致这个类的依赖变得越来越多，功能越来越杂，最终违反了单一功能原则。这虽然不会导致功能异常，但是这将增大后续维护的难度。（话虽然这么说，就算我用了基于构造方法的注入，但是用 Lombok 简化了构造方法，这么一来，增加一个依赖又变得更方便了，只需要加一行变量声明就行，如果在不注重代码质量的时候，这也会加剧类的膨胀。所以最后还是得靠工具和审查流程，以及开发者的自觉，来保证代码质量……）

还有一点我个人的感受，就是基于 field 的注解会占据过多的屏幕空间。按照我个人的代码习惯，每个注入之间都要插入一行空行，来把它们分割开来。这意味着，每个注入都将占据 3 行。如果这个类有过多的依赖，那么很有可能光是依赖注入的部分，就会占据大半个屏幕，这会让我看起来很不舒服。当然，出现这种情况，可能同时也意味着这个类已经过于膨胀，违反单一功能原则了。

基于 setter 的注入和基于构造方法的注入该怎么选择，有什么优点

对于两种注入方式的取舍，Spring 开发团队提供了他们的意见 [^3]：

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的注入。

同时 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. As a side note, a large number of constructor arguments is a bad code smell, implying that the class likely has too many responsibilities and should be refactored to better address proper separation of concerns.
Spring 团队提倡使用基于构造方法的注入，因为这样一方面可以将依赖注入到一个不可变的变量中 (注：final 修饰的变量)，另一方面也可以保证这些变量的值不会是 null。此外，经过构造方法完成依赖注入的组件 (注：比如各个 service)，在被调用时可以保证它们都完全准备好了。与此同时，从代码质量的角度来看，一个巨大的构造方法通常代表着出现了代码异味，这个类可能承担了过多的责任。

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

Setter injection should primarily only be used for optional dependencies that can be assigned reasonable default values within the class. Otherwise, not-null checks must be performed everywhere the code uses the dependency. One benefit of setter injection is that setter methods make objects of that class amenable to reconfiguration or re-injection later.
基于 setter 的注入，则只应该被用于注入非必需的依赖，同时在类中应该对这个依赖提供一个合理的默认值。如果使用 setter 注入必需的依赖，那么将会有过多的 null 检查充斥在代码中。使用 setter 注入的一个优点是，这个依赖可以很方便的被改变或者重新注入。

写在最后

虽然上面洋洋洒洒写 (chao) 了那么多，又是分析优劣，又是分析场景的，但是按照我现在仅有的开发经验来看，好像怎么注入区别都不大 (除了 setter 注入，这个我没用过)，要说我为什么一定要用构造方法注入，最大的原因其实就是为了去掉那个警告……

也有人说，都这么写习惯了，又没出啥问题，你把这个警告关了不就行了吗？我的回答是：

だが断る！

[^1]: Spring Bean: Is autowired attribute initialised before constructor?
[^2]: Field Dependency Injection Considered Harmful
[^3]: Setter-based dependency injection