依赖倒置原则

高层模块不应该依赖于低层模块。两者都应该依赖于抽象。

抽象不应该依赖于细节，细节应该依赖于抽象。

让我们通过一个例子来了解高级模块和低级模块：

在像 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，而不是相反。 这就是为什么这个原理被称为依赖倒置原理

---

依赖注入 VS 依赖反转

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担心实例化依赖项。
这就是依赖注入

的概念

---

控制反转 - IOC

尽管它不是DIP（依赖倒置原理）的一部分，但它是密切相关的

让我们用上面相同的代码来理解这一点

ProductCatalog 类有一个接受 ProductRepository 对象的构造函数。

调用 ProductCatalog 的类将提供或注入 ProductRepository 的对象，在本例中它是 ECommerceMainApplication。
请注意，即使注入发生在 ProductCatalog 类之外，注入仍然发生在程序的主流程中。即注入发生在程序执行的主线程中。

如果我们希望所有注入都发生在单独的线程或单独的上下文中，以便主控制流与注入完全隔离怎么办？

这可以使用 Spring（Java 中）等框架来实现。

Spring 将运行与程序主流程不同的自己的上下文
Spring 将负责注入类所需的依赖项。所以如果你想实例化一个类的对象，你不需要直接在代码中自己做，而是要求 Spring 给你该类的对象。
Spring框架会查看实例化对象所需的所有依赖项，然后继续注入所有依赖项，实例化对象，并将其返回给主控制流。
因此，对依赖注入的控制完全委托给 Spring 框架，并且不会发生在邮件控制流中。
这个概念称为控制反转（IOC），Spring 称为控制反转容器或简称为 IOC 容器

以上是依赖倒置原则的详细内容。更多信息请关注PHP中文网其他相关文章！