Spring IoC 控制反转与依赖注入详解

乍看之下逻辑通顺，但可维护性很差。一旦需求变更，比如要增加轮胎颜色属性，修改点会像多米诺骨牌一样向上蔓延。

假设我们需要给轮胎增加颜色参数，代码改动如下：

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);
    }
}

可以看到，最底层 Tire 的一个小改动，导致整个调用链上的 Bottom、Framework、Car 甚至 Main 方法都需要修改。程序耦合度极高，牵一发而动全身。

解决方案：解耦

为了解决这个问题，我们可以改变依赖方向。不再是上层创建下层，而是下层被上层使用，或者更准确地说，依赖对象由外部传入。

我们将创建子类的行为，改为通过构造函数注入传递的方式。

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 （自上而下创建）
• IoC 模式： Tire -> Bottom -> Framework -> Car （自下而上构建，或由容器组装）

我们发现了一个规律：通用程序的实现中，类的创建顺序往往是反的。传统代码中，使用方对象（Car）控制并创建了依赖对象（Framework），而改进后的控制权发生了反转——不再是由当前类去 new 依赖对象，而是将依赖对象注入到当前对象中。

这意味着，即使依赖类发生任何改变，当前类都不受影响。这就是典型的控制反转（IoC）思想。

那什么是 IoC 容器呢？简单来说，这部分代码的工作就是 IoC 容器做的：

1. 资源集中管理：IoC 容器帮我们管理一些资源（对象等），使用时直接从容器中获取即可。
2. 降低耦合度：创建实例时无需了解细节，降低了使用资源双方的依赖程度。

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

DI：依赖注入

DI 全称为 Dependency Injection（依赖注入）。

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

在前面的代码示例中，我们通过构造函数的形式，把依赖对象注入到了需要使用它的对象中。这其实就是 DI 的一种具体表现形式。

总结来说，IoC 是一种思想，也是目标；而 DI 则是具体的落地方案。可以说，DI 是 IoC 的一种实现方式。在实际开发中，Spring 正是通过 DI 机制来实现 IoC 控制的。