iOS-SOLID原则第5页-依赖倒置原则

DIP —依赖反转原理，指出：

A． 高级模块不应依赖于低级模块。 两者都应依赖 抽象。
B． 抽象不应依赖细节。 细节应取决于抽象。

我将通过提供一些常用实现示例以及该原理说明的内容来尝试解释该原理。

假设您有一个UITableViewController，可显示附近的蓝牙设备。我们将其称为NearestDevicesViewController。

VC及其逻辑是高级模块，它使用服务层中的低级模块， BLEClient或类似的东西。

常见的实现方式是NearestDevicesViewController具有BLEClient属性（并取决于BLEClient属性）。

这种方法根本不灵活。更改BLEClient的工作方式或更改属性以容纳另一个类可能会破坏我们的NearDeviceDevicesViewController 。

更好的方法是使用NearestDevicesViewController需求的抽象。

我们将声明一些协议，例如DevicesProvider 。

该协议将宣布两者之间的“合同”。视图控制器将持有某种符合该协议的类型的属性，从而使其依赖于抽象（协议），并且任何寻求帮助视图控制器的低层模块都将依赖于实现协议中提到的要求。

请注意，这与Liskov替代原则是很好的，因为此“合同”让我们在不更改程序的情况下，将设备提供程序替换为其他任何子类型）

该原理试图颠覆传统方法，即高级模块依赖于低级模块。这种方法中的高级模块拥有抽象（通过确定协议的方法），然后这些低级模块就会遵循该抽象。
使较低级别依赖于较高级别模块的要求。

如上所述，这就是低层和高层模块都依赖抽象的地方（在本例中为协议）：

A． 高级模块不应依赖于低级模块。 两者都应依赖 抽象。

在DevicesProvider的示例中，我们现在可以最大程度地享受灵活性。
例如，如果现在我们想将服务层BLEClient中的类更改为服务层GPSClient中的另一类，则可以通过依赖项注入来注入它，只要它符合DevicesProvider，并且一切都应该很好。

在这里看看我们如何解耦代码。而不是这样：

我们现在有这个：

附近的设备视图控制器未与BLEClient耦合。这意味着我们不必同时使用它们。每个人都可以替换为另一个人，因为它们现在依赖于抽象而不是彼此依赖。

而已。感谢您的支持，并在下面发表评论。
如果喜欢就拍手🙂