快速提醒Swift中的SOLID原则

如果您开始从屋顶盖房子会怎样？墙壁易碎，倾斜角度，基础不稳定。这样的房子寿命不长。该应用程序具有相同的趋势，并取决于开发人员的资格。在我们的领域中，砖是一种编程原理，对系统有不同的影响。我认为SOLID是基本级别。本文的目的是在Swift中提供快速指南或知识更新。

让我们用好与坏的情况来解释该缩写：

1. 单一责任 -每个对象应仅对一种责任作出响应。换句话说，概念模块/类/结构必须响应一个动作。

单一责任-流程不畅

单一责任-流动性好

在这里，我们仅处理OrderType数据，并且可以在没有任何其他条件的情况下对其进行更改。

2. 开闭式 -实体必须开放以进行扩展，但必须封闭以进行修改。

打开关闭 – 流量不好

在我职业生涯的初期，我将更改内部功能，并且可能在数据库处理以及将现有数据相互之间导出时遇到问题。

开闭式-流动性好

更好的方法是在OrderStorage下创建子类并重写方法或准备协议，然后在OrderStorage实现正确的数据处理。换句话说，我们无需内部修改即可扩展存储功能。

3. Liskov替换 -任何对象都可以由其子对象替换，而无需更改应用程序设置。简单地说，如果我们将基类更改为其子应用程序，则该子应用程序将保持稳定，并且新问题不会对其他部分产生影响。

Liskov替代-流动不畅

在那里，我们违反了LS原理。我们通过添加以下条件来更改保存功能： order.products必须具有计数验证。基本RealmOrderStorage不会这样。

有两种解决方案：

Liskov替代-流动性好

在这里，我们不违反基类接口的契约，并且可以在任何地方使用新的子类代替它。 Swift的一项强大功能是面向协议的程序设计，我们可以在不进行子类化的情况下进行工作，但可以通过合同支持设计。

4. 接口隔离 -许多专用接口比一个更好。它们既大又通用。它有助于在使用的项目中划分功能的不同部分，并且不会在那里实现不必要的方法。转到我们的示例：

接口隔离-流量不良

在这里，我们有几种与产品相关的其他方法。那些没有折扣或尺寸设置的产品该怎么办？我们可以陷入陷阱。

接口隔离-良好的流动

在这里，我们可以使用基本接口ProductType进行操作，并根据需要设计其他实例。

5. 依赖倒置 -依赖抽象而不依赖具体。较高的模块不应依赖较低级别的模块。细节必须基于抽象。有很多抽象，实际上在我们的商店中是什么样的？应用程序可以将订单发送到服务器，而API部分对于我们来说是必需的：

依赖倒置-错误的流程

在我们的案例中， StoreService与卖方接口紧密耦合。当我们的工人休假时，无论如何我们都应处理Order 。管理员可以为我们提供帮助，但尚无法为这些更改提供服务。我们应该能够与其他种类的工人一起重用高级模块。

让我们使用VendorType协议解决这种依赖性：

依赖倒置-良好的流程

通过这种方法，我们可以轻松地更换工人。发生这种情况时， StoreService不必更改。同样，此流程有助于我们进行测试。我们可以轻松地使用存根类-实现VendorType和测试方法调用。