iOS-SOLID原则第1页-SRP
SOLID原则是5个OOP设计原则，可帮助您使软件更加灵活，可读性和可维护性。
在这个由五部分组成的系列文章中，我将介绍其中的每一个，并通过示例介绍其中的每一个如何为您提供帮助。
S —单一责任原则（或简称为SRP）
一个模块应该只有一个责任，只有一个改变的理由。
O —打开/关闭原理（OCP）
应该打开一个模块进行扩展，但关闭该模块进行修改。
L — Liskov替换原理（LSP）
程序中的对象应该可以用其子类型的实例替换，而不会改变该程序的正确性。
I —接口隔离原理（ISP）
许多特定于客户端的接口比一个通用接口要好。
D-依赖倒置原则（DIP）
一个人应该“依靠抽象而不是凝结。”
在第一部分中，我将介绍第一个原理SRP。
我认为，这是iOS开发中最重要的5个。
“一个模块应该只有一个责任，只有一个改变的理由。”
从本质上讲，这意味着代码中的对象，类型，类或任何其他模块应负单一责任，这也是更改的唯一理由。
为了说明这一点，假设您有一个应用程序，用户可以在其中设置个人资料图片。 该图像仅显示给用户，因此可以将其存储在磁盘上。
没有SRP，用于编辑个人资料图片的视图控制器将如下所示：
它不在乎也不应该在意如何将食物带到餐桌上。 唯一的责任就是吃它。 他不需要知道您换了工作，升职或被解雇了。 他根本不在乎您如何工作，只要您将他需要的食物带给他即可。 —唯一要担心的是。
我们的下一步将是分离关注点。
就像上面的猫一样，我们的视图控制器不需要知道默认的配置文件资产名称，也不需要知道如何保存它或保存在哪里。 唯一的责任是在UIImageView上显示UIImage。
现在，我们需要一个将处理所有个人资料图片加载和保存的类。
我们可能最终会得到这样的结果：
因此，视图控制器现在看起来像这样：
如我们所见，将个人资料图片管理与视图控制器分离，可以为我们提供更高的可读性和灵活性。
首先，该类现在可以在其他视图控制器中使用，因为我们将个人资料图片管理职责分离到了另一个模块。
现在也阅读视图控制器会更好。 我们只需将图像从ProfilePicManager加载到将在完成时调用的闭包上，然后显示图像。
认为这种方法比第一种更好，但仍不是SRP。 因为如果我们需要保存的图像不是个人资料图片，还会存储更多图像吗？
在前面的示例中，我们将个人资料图片管理与视图控制器分开。 但是我们的ProfilePicManager没有单一职责。 目前它有两件事：
- 个人资料图片管理
- 从存储层获取数据（在这种情况下为文件系统）
从中获取图像或保存图像的方式不是ProfilePicManager的责任或责任。
唯一的工作是从存储层获取个人资料图片，并在用户选择图片时将其交给存储层。
一个模块应该只有一个责任，只有一个改变的理由 。
如果确实要仅更改存储层（例如，从文件系统存储更改为远程服务器存储），而这与ProfilePicManager无关，则也必须更改它。 那不是我们想要的。
在这种情况下，使用SRP，我们只想更改存储层模块。
为了实现这一点，我们将不得不再创建一个类来处理与存储层的通信-ImageStorage 。
唯一的责任是与存储层进行通信。
我们最终可能会遇到以下情况：
所以我们的ProfilePicManager现在看起来像这样：
最后，我们的视图控制器将如下所示：
现在，我们可以看到使用SRP设计模块的优势。
我们的代码更加灵活 ， 可读和可维护 。 例如 –
假设我们现在需要一个新的视图控制器，它将在表格视图中显示所有朋友图像。
例如，我们创建了FriendsImagesManager ，我们仍然可以使用ImageStorage。 由于一次加载许多图像将占用大量内存，因此我们可能想向FriendsImagesManager添加缓存功能。 如果您决定将缓存功能添加到FriendsImagesManager ，则您将更改的唯一类将是FriendImagesManager。
如果我们一直沿用SRP设计，则其他任何类都不知道有任何更改，并且其中的任何代码都不应更改。
如果将来某个时候我们想将图像存储层更改为远程服务器或核心数据，那么我们要做的就是更改ImageStorage。
视图控制器和2个图片管理器都根本不知道更改。
转到第二部分-我们将在此处讨论开放/封闭原则。