SOLID原理与iOS和Swift中的示例（第1部分）

SOLID原则相对较旧，但适用于任何语言的任何OOP代码库的概念都非常有用。

SOLID代表“单一责任原则”，“开放/封闭原则”，“ Liskov替代原则”，“接口隔离原则”和“依赖倒置原则”。 这些原则相互融合并相互支持，是您可以为代码采用的最佳常规设计方法之一。

让我们逐一介绍一下：

单一责任原则：

单一责任原则（SRP）是其中最重要的一项。 它指出，每个模块都应该只有一个责任和变更理由。 SRP从小的具体情况开始，例如类和/或对象仅具有一个目的并且仅用于一件事情。 这个想法是，例如，当您创建一个名为Post的新模型类时，其唯一的目的和职责是保存有关帖子的数据和信息。 这是一个模型类，应该做的更多。 它不应访问数据库以保存自身。 它不应创建基础注释或以任何方式更改它们。 它不应该解析JSON来创建新的发布。 所有这些都是其他对象的单一职责，不应混入该Post类。 Post类只有一个更改的理由-当我们需要在应用程序中更改帖子的数据结构时，它会更改。 它不应更改，因为我们决定将基础数据库从Core Data交换到Realm，或者因为我们的后端决定返回其他类型的JSON。

开/关原则：

打开/关闭原理（OCP）指出，您的模块应打开以进行扩展，但应关闭以进行修改。 这是听起来很容易的事情之一，但是当您开始思考它的含义时，很难把头缠起来。 实际上，这意味着在编写代码时，您应该能够通过使用接口，抽象和依赖注入实现对象，从而通过继承，多态和组合来扩展对象的行为。 假设您拥有一个具有特定接口的PostsStorage类，该接口允许您将Post模型存储在数据库中。 根据该原则，当您想要扩展行为并向PostsStorage添加行为和功能时，您应该能够通过继承以及向该存储注入新的依赖项来做到这一点。 例如，如果您要将存储将帖子保存到的数据库从Core Data更改为Realm，则有两个选择：要么从中继承它的子类，然后覆盖调用Core Data并在其中使用Realm的方法，要么注入另一个数据库适配器/ accessor依赖项与Core Data遵循相同的协议，但在幕后使用Realm。 不过，在这两种情况下，以前使用PostsStorage的每个对象仍应能够像以前一样使用它，而无需进行任何更改，因为在两种情况下，他们所依赖的PostsStorage的界面都没有改变。 我们有效地扩展了PostsStorage行为，而无需对其进行修改。 它很好地与SRP保持一致，因为当我们将基础数据库交换到Realm时， PostsStorage没有理由进行更改。 首先，不是PostsStorage的责任。

装饰器设计模式主要集中在“打开/关闭”原理上。

装饰器是另一个类的包装，可以增强其功能。 它包装了您要装饰的东西，实现了它的接口，并将发送给它的消息委托给基础对象，或者增强了它们或提供了自己的实现。

让我们看下面的例子：

  协议产品{ 
  func price（）->整数 
  func name（）->字符串 

  } 

  class FullPriceProduct：产品{ 

  func price（）-> Int { 
  返回1000 
  } 
  func name（）->字符串{ 
  返回“我是产品” 
  } 
  } 

  class DiscountedProductDecorator类：产品{ 
  私人让装饰的产品：产品 

  初始化（decoratedProduct：产品）{ 
  self.decoratedProduct =装饰产品 
  } 

  func price（）-> Int { 
  返回Int（Float（decoratedProduct.price（））* 0.75） 
  } 

  func name（）->字符串{ 
  返回decoratedProduct.name（） 
  } 

  } 

  类CheckoutManager { 

  func checkout（产品：产品）{ 
  让名称= product.name（） 
  设价格为Double（product.price（）/ 100） 
  打印（“为\（名称）向客户$ \（价格）收费”） 
  } 

 

  让fullPriceProduct = FullPriceProduct（） 
  让DiscountedProduct = DiscountedProductDecorator（decoratedProduct： 

  让checkoutManager = CheckoutManager（） 

  checkoutManager.checkout（product：fullPriceProduct） 
  checkoutManager.checkout（product：discountedProduct 

在这里，我们有一个产品协议，该协议定义了我们所有产品将具有的接口。 有一个FullPriceProduct类可以实现Product协议，它是一个简单的模型类，无关紧要。 我们还有一个Checkout-Manager类，其实例与实现Product协议的对象一起运行。 有趣的是DiscountedProductDecorator 。 它用于对产品应用一个或多个折扣。 它的工作方式是实现Product接口并包装装饰后的产品对象。 它将发送给它的所有消息委派给基础的装饰产品，并在price（）方法中添加（“装饰”）其他行为，以对最终产品价格施加折扣。 最终，您可以将对象包装在多个装饰器中，并像装饰对象一样使用它们，因为它们遵循相同的协议。 产品协议的用户不必知道他们正在使用装饰器来增强原始对象。 我们再次遵守了多种SOLID原则，尤其是开放/封闭原则。

Github Decorator设计模式链接： https : //github.com/ansu/Swift-DesignPatterns/tree/master/Decorator.playground

希望您喜欢这篇文章，在下一篇文章中，如果喜欢，请随时点击below下面的鼓掌按钮以帮助其他人找到它！ 我将编写扩孔三项SOLID原则。