高层模块不应该依赖于低层模块。两者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
让我们通过一个例子来了解高级模块和低级模块：
在像 Flipkart 这样的电子商务应用程序中，它可以被分类为 ProductCatalog、PaymentProcessor 和 CustomerProfile（这些是一些主要的业务功能）
这些业务功能相互依赖于上图所示的其他模块。
注意：顶部的模块更接近于称为高级级别模块的业务功能。
底部的模块接近称为低级别模块的实现细节。
低级模块是 SQLProductRepository、GooglePayService、WireTransfer、EmailSender 和 VoiceDialer。
如果我们单独考虑CustomerProfile（高级模块）和Communication模块，那么Communication是一个低级模块，但是如果我们单独考虑Communication、EmailSender和VoiceDialer那么，Communication成为一个高级模块，而EmailSender和VoiceDialer 是低级模块。
这里的重点是高低层模块的概念不是绝对的，而是相对。
根据上图，ProductCatalog 依赖于 SQLProductRepository，即高级模块依赖于低级模块，但这直接与 DIP 的第一个定义冲突。
让我们采用 ProductCatalog → SQLProductRepository 关系并进一步分析它。
import java.util.List;
/*
* High-Level module
*/
public class ProductCatalog {
public void listAllProducts(){
SQLProductRepository sqlProductRepository = new SQLProductRepository();
List<String> allProductsNames = sqlProductRepository.getAllProductNames();
//Display all products names
}
}
/*
* Low-level module
*/
import java.util.Arrays;
import java.util.List;
public class SQLProductRepository {
public List<String> getAllProductNames(){
return Arrays.asList("soap","toothpaste");
}
}
由于 ProductCatalog 直接依赖于 SQLProductRepository，这显然违反了 DIP 定义 1（根据定义 高级模块和低级模块都应依赖于抽象）
让我们根据定义 1 修复此问题：
创建接口 ProductRepository
import java.util.List;
public interface ProductRepository {
public List<String> getAllProductNames();
}
在 SQLProductRepository 中实现此接口
/*
* Low-level module
*/
import java.util.Arrays;
import java.util.List;
public class SQLProductRepository implements ProductRepository{
@Override
public List<String> getAllProductNames(){
return Arrays.asList("soap","toothpaste");
}
}
最后，对于高级模块 ProductCatalog，我们不应该直接在其中实例化 SQLProductRepository。我们将使用 ProductFactory 类来实现相同的
public class ProductFactory {
public static ProductRepository create(){
return new SQLProductRepository();
}
}
我们将使用 ProductFactory 实例化 SQLProductRepository
/*
* High-Level module
*/
import java.util.List;
public class ProductCatalog {
public void listAllProducts(){
ProductRepository productRepository = ProductFactory.create();
List<String> allProductsNames = productRepository.getAllProductNames();
//Display all products names
}
}
注意我们的引用对象是 ProductRepository 因此，我们与 SQLProductRepository 没有任何紧密耦合
修改后，新的依赖项将如下所示
以上更改符合 DIP 定义 1。
上面的代码更改也遵循 DIP 的第二个定义，即抽象不应该依赖于细节，细节应该依赖于抽象。
正如我们在上图中看到的，SQLProductRepository 依赖于 ProductRepository，而不是相反。 这就是为什么这个原理被称为依赖倒置原理
Even though they are related, they are not the same and can not be used interchangeably
理解依赖注入：
在 ProductCatalog 中，我们使用工厂方法 ProductFactory.create() 来获取 SQLProductRepository 对象的实例。
虽然它将实例创建过程委托给工厂类 ProductFactory，但初始化过程仍然由 ProductCatalog 类完成。
理想情况下，我们不希望 ProductCatelog 类担心如何以及何时触发实例化。
如果我们向 ProductCatalog 提供实例化的 ProductRepository 类，即使它没有询问，会怎么样？
因此，Main 类 ECommerceMainApplication 使用工厂方法 ProductFactory.create() 来创建 ProductRepository 的实例，并且该实例作为参数传递到 ProductRepositroy 类的构造函数中。
public class ECommerceMainApplication {
public static void main(String agrs[]) {
ProductRepository productRepository = ProductFactory.create();
ProductCatalog productCatalog = new ProductCatalog(productRepository);
productCatalog.listAllProducts();
}
}
相应更新 ProductCatalog 类后
import java.util.List;
public class ProductCatalog {
private ProductRepository productRepository;
public ProductCatalog(ProductRepository productRepository) {
this.productRepository = productRepository;
}
public void listAllProducts(){
List<String> allProductsNames = productRepository.getAllProductNames();
//Display all products names
allProductsNames.forEach(product-> System.out.println(product));
}
}
现在，ProductCatalog 可以随时随地自由使用 SQLProductRepository 对象。它不再担心自己创建 SQLProductRepository 对象。
换句话说我们将依赖项注入到ProductCatalog中，而不是ProductCatalog担心实例化依赖项。
这就是依赖注入
尽管它不是DIP（依赖倒置原理）的一部分，但它是密切相关的
让我们用上面相同的代码来理解这一点
ProductCatalog 类有一个接受 ProductRepository 对象的构造函数。
调用 ProductCatalog 的类将提供或注入 ProductRepository 的对象，在本例中它是 ECommerceMainApplication。
请注意，即使注入发生在 ProductCatalog 类之外，注入仍然发生在程序的主流程中。即注入发生在程序执行的主线程中。
如果我们希望所有注入都发生在单独的线程或单独的上下文中，以便主控制流与注入完全隔离怎么办？
这可以使用 Spring（Java 中）等框架来实现。
Spring 将运行与程序主流程不同的自己的上下文
Spring 将负责注入类所需的依赖项。所以如果你想实例化一个类的对象，你不需要直接在代码中自己做，而是要求 Spring 给你该类的对象。
Spring框架会查看实例化对象所需的所有依赖项，然后继续注入所有依赖项，实例化对象，并将其返回给主控制流。
因此，对依赖注入的控制完全委托给 Spring 框架，并且不会发生在邮件控制流中。
这个概念称为控制反转（IOC），Spring 称为控制反转容器或简称为 IOC 容器
以上是依赖倒置原则的详细内容。更多信息请关注PHP中文网其他相关文章！
