iOS-SOLID原则第4页-接口隔离原则

---

接口隔离原理说：

“许多特定于客户端的接口比一个通用接口要好。”

在iOS中，该主题中的Interface可以转换为Protocol。

它说，许多协议要比具有一个通用目的的一个大协议（或类，结构或枚举）更好。

---

客户特定协议将是某些客户只需要的协议。
假设您有两个课程：
猫与人 ：

 类Human {func work（）{} func sleep（）{} func GiveFood（）-> Food {return Food（）} //其他功能} class Cat {var owner：Human var foodBowl：[Food] = [] 
  func requestFood（）{print（“ Meow，gimme food”）let foodScoop = self.owner.feedPet（）self.foodBowl.append（foodScoop）} 
  func eat（）{self.foodBowl.removeAll（）} init（owner：Human）{self.owner = owner}} 

如您所见， Cat是Human的客户。 它消耗人类的数据。
猫不能告诉它的主人去工作，也不需要知道那件事。
在此示例中，所有者需要的只是食物。

---

这就是隔离的来历。
正如我们所说，猫只在乎他的食物。
Cat没有理由暴露于类似于work（）或sleep（）之类的人类功能。

所以我们可以声明一个PetFoodProvider协议：

 协议FoodProvider {func feedPet（）-> Food} 

因此，我们的客户（ Cat ）将仅使用（并将暴露给它）所需的东西：

  var foodProvider：FoodProvider 

而且我们可以在我们的Human结构（甚至在我们的自动猫喂食器机器）中做到这一点：

  struct Human：FoodProvider .... 

---

这样解耦类型和协议有很多好处。
一个经典的例子是将我们的Human work（）函数隔离到一个新协议中：

 协议工作者{func work（）} 

然后我们可以编写一个雇主协议：

 协议雇主{var employee：[Worker] {get set}} 

只要工人在工作， 雇主就不必知道或关心工人的身份。 现在，不仅人类在工作，对吗？ 机器人也可以遵守该协议。

如果我们声明了所有Human功能（一个通用目的）并且我们希望work（）被Robot采用，我们将继承Human并获得一些我们并不想要的功能，例如sleep（）。 机器人不睡觉。
这就是为什么…：

“许多特定于客户端的接口比一个通用接口要好。”

---

我们可以声明一个Cat和Human都可以采用的Sleeper协议。 谁知道有一天我们会有Bed结构，该结构的属性如下：

  var currentSleeper：卧铺 

接口隔离使您可以灵活地做到这一点。
它同时还为您提供了可重用性，更不用说它如何与我们之前讨论的前三个原理完美地结合了。

---

现在，最后一部分- 依赖反转原理。