为什么使用构造注入而不是Autowired

使用Spring开发时，我们通常有两种依赖注入的方式，基于注解@Autowired的依赖注入和基于构造函数的依赖注入。

用IDEA开发过程中，如果使用@Autowired注入，通常会有如下警告

warn.png

Inspection info: Spring Team recommends: "Always use constructor based dependency injection in your beans. Always use assertions for mandatory dependencies".

翻译成中文：
spring 团队建议：“在bean中始终使用基于构造函数的依赖注入，始终使用断言来强制依赖”。

为什么spring团队会这样建议呢？

可能会出现空指针异常

首先我们看一个使用@Autowired注入的简单例子：

public class Car {

    @Autowired
    private Wheel wheel;

    public void run() {
        wheel.roll();
    }
}

假设测试代码如下，就会发生空指针异常：

Car car = new Car();
car.run();// -> NullPointerException

出现这种问题的关键在于，Car允许创建无状态的对象，也就是说在构建Car时允许Wheel为空。

下面我们使用构造注入的方式：

public class Car {

    private final Wheel wheel;

    public Car(Wheel wheel) {
        Assert.notNull(wheel,"Wheel must not be null");
        this.wheel = wheel;
    }

    public void run() {
        wheel.roll();
    }

}

这样我们就有如下优点：

• 在创建Car对象的时候，强制依赖Wheel对象，确保创建Car对象时每个对象都是有效状态。
• 构造器中可以添加对象初始化的校验逻辑
• 可以清楚的区分对象是通过setter方法注入的（非final对象）还是通过强制依赖注入的（final对象）

构造注入代码变得臃肿？

或许有的读者可能会说，构造注入的话，如果依赖的对象很多，构造器参数就会很多，显得代码很臃肿。这种情况的话，就要考虑这个类是符合足单一职责原则了，将这个类拆分为多个类。

而且使用@Autowired的自动装配会让依赖对象变得很容易，随着项目的迭代，自动注入的对象可能会变得很多，但是使用构造注入，构造器就会变得很臃肿，提醒你代码里有bad smell了，需要拆分或重构代码了。

还有一个问题是@Autowired注入的对象无法使用final关键字，因为final对象必须在构造器中初始化。

@Autowired测试不友好

使用注解的自动装配，我们的业务代码确实会变得比较少，但是单元测试该如何写呢？

        Wheel wheel = Mock(Wheel);
        Car car = new Car();
        //通过反射来将wheel对象注入到Car对象里
        car.run();

通过反射注入到Car对象里，我们的单元测试代码就会显得很繁琐，或者在Car对象里提供一个Wheel的setter方法？这样代码不是很优雅。

如果是构造注入，单元测试就会变成如下：

        Wheel wheel = Mock(Wheel);
        Car car = new Car(wheel);
        car.run();

单元测试代码就会变得很优雅，而且在后续的开发中，如果Car对象添加了强制依赖的Tank对象，单元测试也不会出现没有设置的强制依赖项。

Spring 的DI设计模式，是将依赖关系的创建和类本身分离，将依赖关系创建的职责交给了类注入器做，允许程序设计的松耦合，并遵循单一职责原则和依赖反转原则。因此使用@Autowired自动装配的字段在Spring容器之外无法使用（不包含通过反射设置对象的方式）。

构造注入可以在受影响的类中轻松表明对象的依赖关系，但是@Autowired的自动装配其实对外隐藏了这些依赖关系，需要到对应的类中查看代码才能明确依赖。

使用Lombok来解决构造注入样板代码的问题

Lombok是一个强大的java样板代码解决方案，这里来介绍下使用Lombok简化构造注入的代码：

@RequiredArgsConstructor
public class Car {

    private final @NonNull Wheel wheel;

    public void run() {
        wheel.roll();
    }

}

@RequiredArgsConstructor注解会在编译过程中，将所有的final对象作为参数添加到构造器中。

小结

下面我们来总结下注解注入和构造注入的优缺点：

注解注入

++ 写更少的代码
-- 代码变得不安全
-- 单元测试会比较复杂
-- 无法使用fianl对象
-- 违反单一职责原则变得很容易
-- 对受影响的类隐藏自己的依赖关系

构造注入

++ 更安全的代码
++ 测试友好
++ 依赖添加代价较高，显式的表明代码的bad smell
++ 在受影响的类中显式的表明依赖关系
-- 需要写更多的业务代码（可以通过Lombok解决）

参考文章

• Field injection is not recommended – Spring IOC
• Why field injection is evil