转载

Effective Java学习笔记（四）依赖注入

本文对应原书条目5，主要解释当一个类需要依赖底层资源时的一种有效引入底层资源的方式—— 依赖注入 （Dependency Injection, DI）。如有问题或建议，欢迎联系我，谢谢~

什么是依赖注入？

让我们看看下面这个 Car 类，它依赖了一个底层资源 Engine 。传统的方式是在需要调用 Engine 的地方 new 一个出来。如下所示。

public class Car {

    public void run() {
        Engine engine = new Engine();
        engine.ignite();
        engine.shutDown();
    }
}

传统地，如果一个类A依赖了另一个类B，在类A的相关方法里要自行 new 出一个B的对象，然后去管理B对象的生命周期，这样就把两个类强耦合在一起了。类A不光要管好自己的业务逻辑，还要负责维护对象B的生命周期。

如果类A的多个方法里都要用到对象B，那你有可能会把对象B变成一个类A的成员变量，如下所示。

public class Car {
    private final Engine engine = new Engine();

    public void ignite() {
        engine.ingite();
        // 打开其他的部件
    }

    public void shutDown() {
        engine.shutDown();
        // 关闭其他的部件
    }
}

这样一来，类 Car 里的成员变量 engine 可以在 Car 对象里的所有方法中被使用了。但这样还是有问题的，有两点需求还是不能被满足。1）哪一天需要把 Engine 替换成 NewEngine ，还需要改代码；2）不同的 Car 对象可能需要不同的 Engine 。

因此我们就需要能够有方法把 Car 依赖的 Engine 这个资源注入进来。一般可以通过构造方法和 setter 方法注入依赖的资源，如下所示。

public class Car {
    private IEngine engine;

    public Car(IEngine engine) {
        this.engine = engine;
    }

    public void ignite() {
        engine.ingite();
        // 打开其他的部件
    }

    public void shutDown() {
        engine.shutDown();
        // 关闭其他的部件
    }

    public void setEngine(IEngine engine) {
        this.engine = engine;
    }
}

这里我们可以看到 engine 从一个类变成了一个接口，这样做是为了支持为不同的 Car 对象注入不同的 IEngine 实现。实际调用的时候需要我们自己去注入 engine ，如下所示。

...
    IEngine engineA = new EngineA();
    // 用构造器的方式注入
    Car car = new Car(engineA);
    car.iginte();
    IEngine engineB = new EngineB();
    // 用setter的方式注入
    car.setEngine(engineB);
    ...

个人认为还是用构造器的方式注入资源会比较好，开放了 setter 权限会让依赖的资源随意可变，从而变得混乱。

依赖注入框架

上面这种依赖注入是依靠客户端代码去实现的，还是不够便利，所幸我们有 Spring 这种现代化的依赖注入框架，帮助我们去更好地实现依赖注入。像Spring这种容器主要是通过 控制翻转 (Inversion of Control, IoC)的方式实现依赖注入的。

那么怎么去理解这个控制反转呢？

原本需要我们程序员自己去创建一个对象A，然后在程序里再去创建它所依赖的对象B，再把对象B注入给对象A，这个控制权在程序上面。而控制反转是指你把这个创建依赖对象的职责交付给容器（即把对象的控制权交给容器）。你只要把自己写的类交托给IoC容器（比如Spring中的 @Component 注解），然后再告诉容器什么地方需要注入这个资源(我们常用的 @Autowired 注解)，容器会通过反射的方式在一个对象创建的时候去自动地创建它所依赖的资源对象。程序员只需要去打造一个个组件，把拼接的工作交给IoC容器来完成。

依赖注入的适用场景

依赖注入适用于那些依赖了底层资源，且底层资源可能有多种实现的类。这种类一般不能实现为静态工具类或者单例。因为前者所依赖的资源必须以 static 修饰且类本身一般不能支持实例化，而后者必须自己实现自己的实例化。所以这两种形式所依赖的资源和这些资源的初始化必须在自己的类里面写死，不是我们能控制的。也就是说“静态工具类和单例类不适合于需要引用底层资源的类”。 ^[1]