一、前言

    使用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 { @Autowired private 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解决）