Spring IoC 与依赖注入核心原理

乍看之下，这段代码逻辑通顺。但一旦需求变更，比如要增加轮胎颜色属性，问题就暴露了。我们需要在 Tire 类加字段，然后 Bottom、Framework、Car 甚至 Main 方法都要跟着改。最底层变动会引发调用链上所有代码的连锁反应，耦合度极高，维护成本随之飙升。

修改后的完整代码如下：

public class Main {
    public static void main(String[] args) {
        Car car = new Car(21, "aaa");
        car.run();
        Car car2 = new Car(17, "bbb");
        car2.run();
    }
}

// 汽车
class Car {
    private Framework framework;
    public Car(int size, String color) {
        framework = new Framework(size, color);
        System.out.println("framework init...");
    }
    public void run() {
        System.out.println("car run...");
    }
}

// 车身
class Framework {
    private Bottom bottom;
    public Framework(int size, String color) {
        bottom = new Bottom(size, color);
        System.out.println("bottom init....");
    }
}

// 底盘
class Bottom {
    private Tire tire;
    public Bottom(int size, String color) {
        tire = new Tire(size, color);
        System.out.println("tire init...");
    }
}

// 轮胎
class Tire {
    private int size;
    private String color;
    public Tire(int size, String color) {
        System.out.println("tire size:" + size + ",color:" + color);
    }
}

可以看到，只要最底层改动，整个调用链上的所有代码都需要修改。这就是高耦合带来的麻烦。

解决方案：依赖注入

为了解耦，我们尝试改变实现方式：让依赖关系反向流动。即轮胎依赖底盘，底盘依赖车身，车身依赖汽车。更准确地说，是上层对象不再主动创建下层对象，而是由外部传入。

我们将创建子类的行为改为注入传递的方式。改造后的代码如下：

class Main {
    public static void main(String[] args) {
        Tire tire = new Tire(17, "red");
        Bottom bottom = new Bottom(tire);
        Framework framework = new Framework(bottom);
        Car car = new Car(framework);
        car.run();
    }
}

// 汽车
class Car {
    private Framework framework;
    public Car(Framework framework) {
        this.framework = framework;
        System.out.println("framework init...");
    }
    public void run() {
        System.out.println("car run...");
    }
}

// 车身
class Framework {
    private Bottom bottom;
    public Framework(Bottom bottom) {
        this.bottom = bottom;
        System.out.println("bottom init....");
    }
}

// 底盘
class Bottom {
    private Tire tire;
    public Bottom(Tire tire) {
        this.tire = tire;
        System.out.println("tire init...");
    }
}

// 轮胎
class Tire {
    private int size;
    private String color;
    public Tire(int size, String color) {
        System.out.println("tire size:" + size + ",color:" + color);
    }
}

经过调整，无论底层类如何变化，只要接口不变，整个调用链就不需要做任何修改。这就实现了代码之间的解耦，让程序设计更加灵活通用。

IoC 的优势

对比两种模式，传统代码的对象创建顺序是：Car -> Framework -> Bottom -> Tire。而改进后的解耦代码，对象创建顺序变成了：Tire -> Bottom -> Framework -> Car。

我们发现了一个规律：通用程序的实现中，类的创建顺序往往是反的。传统模式中，使用方对象（如 Car）控制并创建了依赖对象（Framework），层层向下；而改进之后，控制权发生了反转。不再是使用方对象去创建和控制依赖对象，而是将依赖对象注入到当前对象中。依赖对象的控制权不再由当前类掌握。

这样一来，即使依赖类发生任何改变，当前类都不受影响。这就是典型的控制反转，也是 IoC 的核心思想。

那么什么是 IoC 容器呢？它负责执行这部分工作：

IoC 容器具备以下显著优点：

1. 资源集中管理：资源不由使用资源的双方直接管理，而是由不直接使用资源的第三方（容器）管理。这带来了极大的便利，IoC 容器帮我们管理对象等资源，使用时直接从容器中获取即可。
2. 降低耦合度：我们在创建实例时无需了解内部细节，降低了使用资源双方的依赖程度。

Spring 就是一种 IoC 容器，它帮助我们完成了这些资源管理工作。

DI：依赖注入

DI 全称 Dependency Injection（依赖注入）。当容器运行期间，动态地为应用程序提供运行时所依赖的资源，这个过程就称为依赖注入。

程序运行时需要某个资源，此时容器就为其提供这个资源。从这点来看，依赖注入（DI）和控制反转（IoC）是从不同角度描述同一件事情：都是通过引入 IoC 容器，利用依赖关系注入的方式，实现对象之间的解耦。

在前面的代码示例中，我们通过构造函数的参数，把依赖对象注入到了需要使用它的对象中。

总结来说，IoC 是一种思想，也是一种目标，它指导我们如何设计系统以降低耦合；而 DI 则是具体的落地方案，是实现 IoC 的一种手段。所以也可以说，DI 是 IoC 的具体实现。