高层模块不应该依赖于低层模块。两者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
让我们通过一个例子来了解高级模块和低级模块：
在像 Flipkart 这样的电子商务应用程序中，高层次上它可以分为 ProductCatalog、PaymentProcessor 和 CustomerProfile（这些是一些主要业务功能）
这些业务功能相互依赖于上图所示的其他模块。
注意：上面的模块更接近业务功能，称为高级别模块。
底部的模块接近称为低级别模块的实现细节。
低级模块是 SQLProductRepository、GooglePayService、WireTransfer、EmailSender 和 VoiceDialer。
如果我们单独考虑CustomerProfile（高级模块）和Communication模块，那么Communication是一个低级模块，但是如果我们单独考虑Communication、EmailSender和VoiceDialer，那么Communication就成为一个高级模块，而EmailSender和VoiceDialer是低级模块。
这里的重点是高低层模块的概念不是绝对的，而是相对的。
根据上图，ProductCatalog 依赖于 SQLProductRepository，即高级模块依赖于低级模块，但这直接与 DIP 的第一个定义相冲突.
让我们进一步分析 ProductCatalog → SQLProductRepository 关系。
由于 ProductCatalog 直接依赖于 SQLProductRepository，这显然违反了 DIP 定义 1（根据定义高级模块和低级模块都应依赖于抽象）
让我们根据定义 1 修复此问题：
创建接口ProductRepository
在SQLProductRepository中实现该接口
最后，对于高级模块 ProductCatalog，我们不应该直接在其中实例化 SQLProductRepository。我们将使用 ProductFactory 类来实现相同的目的
我们将使用 ProductFactory 实例化 SQLProductRepository
注意我们的引用对象是 ProductRepository 所以，我们与 SQLProductRepository 没有任何紧密耦合
修改后，新的依赖项将如下所示
以上更改按照 DIP 定义 1.
上面的代码更改也遵循 DIP 的第二个定义，即抽象不应该依赖于细节，细节应该依赖于抽象。
正如我们在上图中看到的，SQLProductRepository 依赖于 ProductRepository，而不是相反。这就是为什么这个原理被称为依赖倒置原理
理解依赖注入：
在 ProductCatalog 中，我们使用工厂方法 ProductFactory.create() 来获取 SQLProductRepository 对象的实例。
虽然它将实例创建过程委托给工厂类 ProductFactory，但初始化过程仍然由 ProductCatalog 类完成。
理想情况下，我们不希望 ProductCatelog 类担心如何以及何时触发实例化。
如果我们向 ProductCatalog 提供实例化的 ProductRepository 类，即使它没有询问，会怎么样？
因此，Main 类 ECommerceMainApplication 使用工厂方法 ProductFactory.create() 来创建 ProductRepository 的实例，并且该实例作为参数传递到 ProductRepositroy 类的构造函数中。
相应更新 ProductCatalog 类后
现在 ProductCatalog 可以随时随地自由使用 SQLProductRepository 对象。它不再担心自己创建 SQLProductRepository 对象。
换句话说，我们将依赖项注入到 ProductCatalog 中，而不是让 ProductCatalog 担心实例化依赖项。
这就是依赖注入的概念
虽然它不是DIP（依赖倒置原理）的一部分，但它是密切相关的
让我们用上面相同的代码来理解这一点
ProductCatalog 类有一个接受 ProductRepository 对象的构造函数。
调用 ProductCatalog 的类将提供或注入 ProductRepository 的对象，在本例中它是 ECommerceMainApplication。
请注意，即使注入发生在 ProductCatalog 类之外，注入仍然发生在程序的主流程中。即注入发生在程序执行的主线程中。
如果我们希望所有注入都发生在单独的线程或单独的上下文中，以便主控制流与注入完全隔离，该怎么办？
这可以使用像Spring（Java 中）这样的框架来实现。
Spring 将运行自己的上下文与程序的主流程不同
Spring 将负责注入类所需的依赖项。所以如果你想实例化一个类的对象，不要直接在代码中自己做，而是要求 Spring 给你该类的对象。
Spring框架查看实例化对象所需的所有依赖项，然后继续注入所有依赖项，实例化对象，并将其返回给主控制流。
因此，对依赖注入的控制完全委托给 Spring 框架，并且不会发生在邮件控制流中。
这个概念称为控制反转（IOC），Spring 称为控制反转容器或简称为IOC 容器
以上是依赖倒置原则的详细内容。更多信息请关注PHP中文网其他相关文章！
