为什么使用构造注入而不是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

你可能感兴趣的:(为什么使用构造注入而不是Autowired)