一、前言

    使用Spring开发时，我们通常有两种依赖注入的方式，基于注解@Autowired的依赖注入和基于构造函数的依赖注入。用IDEA开发过程中，如果使用@Autowired注入，通常会有如下警告:

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

翻译成中文：

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

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

可能会出现空指针异常

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

public class Car {@Autowiredprivate Wheel wheel;public void run() {wheel.roll();}
}

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

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

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

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

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的自动装配其实对外隐藏了这些依赖关系，需要到对应的类中查看代码才能明确依赖。

三、总结

注解注入优缺点

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

构造注入优缺点

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