依赖倒置原则 Dependency Inversion Principle - DIP
基本知识
1.依赖倒置原则（DIP）是面向对象设计（OOD）中的五个基本原则之一，通常被称为 SOLID 原则中的 D
2.核心思想：
高层模块不应该依赖低层模块，两者都应该依赖抽象。 (High-level modules should not depend on low-level modules. Both should depend on abstractions.)
抽象不应该依赖于细节，细节应该依赖于抽象。 (Abstractions should not depend on details. Details should depend on abstractions.)
简单来说，DIP 提倡的是在软件设计中，我们应该让依赖关系指向抽象（如接口或抽象类），而不是具体的实现（如具体的类）。这颠覆了传统上高层模块直接依赖低层模块的“自上而下”的依赖关系，从而实现了“倒置”的效果。
3.依赖：
“依赖”指的是一个软件构件（例如一个类、一个模块、一个组件或一个系统）需要另一个构件才能正常工作或完成其功能。
常见四种依赖：
1.编译时依赖：个类 A 的代码中引用了类 B 的成员变量、方法、常量、类型定义（如作为参数类型、返回类型、局部变量类型、父类或接口）
class B {public void doSomething() { /* ... */ }
}class A {private B bInstance; // A 依赖 B 作为成员变量public void methodA(B param) { // A 依赖 B 作为方法参数B localB = new B(); // A 依赖 B 作为局部变量和构造函数param.doSomething(); // A 依赖 B 的方法}
}
2.运行时依赖：
即使在编译时没有直接引用，但在程序运行时，构件 A 可能需要构件 B 提供的服务或数据。例如：反射时候A需要使用B的方法，虽然编译A的时候不需要B，但是运行时候B需要存在。又例如：配置文件
3.直接依赖和间接依赖：构件A直接引用构件B称为直接依赖，而构件A依赖构件B，构件B依赖构件C，此为间接依赖
4.接口依赖和实现依赖：
接口依赖 Interface Dependency：一个构件依赖另一个构件的接口
实现依赖 Implementation Dependency：一个构件依赖另一个构件的具体实现类。这种会造成紧耦合，DIP正是为了避免这种依赖。
例子：
class A { private List<String> list; }：A 依赖于 List 接口（接口依赖）。
class A { private ArrayList<String> list; }：A 依赖于 ArrayList 具体实现类（实现依赖）
具体实例
1.没有实现DIP的情况
即传统的高层模块直接依赖低层模块
public class Bike {public void take(){System.out.println("骑自行车");}
}
public class Car {public void run(){System.out.println("开车");}
}
public class Human {private Bike bike;private Car car;public Human(){this.bike=new Bike();this.car=new Car();}public void driverCar(){this.car.run();}public void takeBike(){this.bike.take();}
}
public class Test {public static void main(String[] args) {Human human=new Human();human.driverCar();human.takeBike();}
}高层模块Human类依赖Bike类和Car类，在human类中声明了两个成员变量，分别时Bike类和Car类，并在构造方法中实例化了Bike类和Car，这些都明显违反了DIP，有强耦合情况。
那么违反DIP的问题：
1.难以扩展，比如我们后面如果引入另外的交通工具，比如MotoCycle，或者Bus,或者Subway,那么我们必须修改Human类，添加对应的成员变量，然后进行实例化，再写新的方法。
2.难以测试，如果想单独测试 Human 类（例如，测试 driverCar 方法的逻辑，但不真正涉及到实际的汽车运行），很难对 Bike 和 Car 进行模拟或替换，因为它们在 Human 内部被硬编码创建了。
2.使用DIP
public interface ITransportation {void take();
}
public class Bike implements ITransportation{@Overridepublic void take() {System.out.println("骑自行车");}
}public class Bus implements ITransportation{@Overridepublic void take() {System.out.println("坐汽车");}
}
public class Car implements ITransportation{@Overridepublic void take() {System.out.println("开车");}
}
public class Human {private ITransportation transportation;//依赖抽象接口/*通过构造方法注入依赖*/public Human(ITransportation iTransportation){this.transportation=iTransportation;}public void take(){transportation.take();}}
ublic class Test {public static void main(String[] args) {Bike bike = new Bike();Human human = new Human(bike);human.take();Bus bus =new Bus();Human human1=new Human(bus);human1.take();Car car = new Car();Human human2 = new Human(car);human2.take();}
}这段代码中，我们使用ITransportation 接口。这是一个抽象，定义了“交通工具”应该具备的通用行为 take()。
低层模块依赖抽象：Bike, Bus, Car 类。这三个类是具体的低层实现（细节）。
它们都实现了 ITransportation 接口。这意味着它们现在依赖于这个抽象来提供其具体功能。它们不是独立的，而是受 ITransportation 接口定义的约束。
高层模块依赖抽象：Human 类
Human 类是高层模块，它需要使用交通工具。
private ITransportation transportation;：Human 类内部声明了一个 ITransportation 类型的成员变量，而不是具体的 Bike、Bus 或 Car 类型。这表明 Human 依赖于抽象。
依赖注入（通过构造函数）：
public Human(ITransportation iTransportation){this.transportation=iTransportation;
}
Human 不再在自己的内部（比如构造函数中）实例化具体的交通工具。相反，它通过构造函数接收一个已经创建好的 ITransportation 实例。这是一种经典的依赖注入方式。Human 不知道它会具体操作的是自行车、巴士还是汽车，它只知道如何与任何实现了 ITransportation 接口的对象进行交互。
而“细节应该依赖于抽象” 这句话，在代码例子中，正是对应 Car, Bus, Bike 实现 ITransportation 接口的情况。
细节（Details）：在这里指的是 Car、Bus 和 Bike 这些具体的实现类。它们包含了实现“交通工具”功能的具体细节，比如 System.out.println(“开车”) 或 System.out.println(“骑自行车”)。
抽象（Abstractions）：在这里指的是 ITransportation 接口。它定义了一个通用的契约：任何实现了它的类都必须提供一个 take() 方法。
“依赖于”：通过 implements 关键字，Car、Bus 和 Bike 在编译时就被强制要求遵循 ITransportation 接口的规范。它们的实现必须符合接口的定义。如果它们不实现 take() 方法，或者方法签名不正确，编译器就会报错。
倒置”的效果：
在旧的代码中：Human (高层) -> Bike (低层), Human (高层) -> Car (低层)。
在这段代码中：
Human (高层) -> ITransportation (抽象)。
Bike, Bus, Car (低层) -> ITransportation (抽象)。
依赖关系不再是高层指向具体的低层，而是高层和低层都指向了同一个抽象。这正是依赖关系的“倒置”。
回顾下
回顾最初的两句话：
高层模块不应该依赖低层模块，两者都应该依赖抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
显然，我们看到Human这个高层模块里面有抽象接口的成员变量，故高层模块依赖抽象。对于低层模块Car,Bus,Bike。我们可以看到“一个类 A 的代码中引用了类 B 的…接口”中对应上：A是Car类，B是ITransportation 接口。即A引用B类型作为接口
Car 类的代码中，明确地使用了 ITransportation 这个接口类型：
public class Car implements ITransportation
所以低层模块也是依赖抽象的。这种依赖是通过 implements 关键字在编译时建立的，它强制 Car 去遵守 ITransportation 定义的契约
符合 DIP 带来的好处：
降低耦合度： Human 类不再知道任何关于 Bike、Bus 或 Car 具体实现的信息。它只关心 ITransportation 接口。
提高可扩展性： 如果将来需要增加新的交通工具（例如 Train, Airplane），只需要创建新的类实现 ITransportation 接口即可，无需修改 Human 类的任何代码。这完全符合开闭原则。
提高可测试性： 在测试 Human 类时，可以很容易地创建 ITransportation 接口的模拟（Mock）实现，以便隔离测试 Human 自身的逻辑，而无需依赖真实的交通工具。
提高可维护性： 交通工具的实现细节变化不会影响到 Human 类。