原文在 这里，里面还包含很多TIPS
在Objective-C的世界中有一处很重要的缺失，它是最近几十年抽象接口的产物。术语“接口”通常用于指代一个类的.h文件，但它也有Java程序员熟知的另一个意义，那就是用于描述一些没有具体实现的方法。在Objective-C中，后一种情况通过使用协议来实现。由于历史原因，协议（类似Java接口的使用方法）在Objective-C代码中一般不会使用。这主要是因为苹果开发的大多数代码都不接受这种方法，几乎所有开发人员都倾向于遵循苹果的开发模式和推荐方法。苹果几乎只用协议来实现代理模式（delegate）。抽象接口的概念非常强大，它以计算机科学的历史为根源，所以没有任何理由不用于Objective-C。
下面将通过具体的例子来介绍协议（作为抽象接口功能）的强大作用：从非常糟糕的设计架构 到一段非常好的可重用代码。
提供的示例是实现一个“RSS订阅 阅读器”（它的功能就是在这个阅读器上可以展示多个你订阅的网站或者博客）。
要求很简单：在TableView中显示远程RSS订阅信息。
一个非常天真的方案是创建一个UITableViewController，并对整个逻辑进行编码以得到订阅的数据，解析和显示在一个地方，换句话说就是MVC（Massive View Controller 调侃）。这样做可以完成，但是设计很差。不幸的是在一些不那么苛刻的创业公司中这样做足够了。
最基本的一个步骤是遵循单一责任原则，并创建至少两个组件来执行不同任务：
* “订阅 解析器” 用来解析从端点收集来的数据
* “订阅 阅读器” 用来显示数据
对于这些类的接口可以是这样：
ZOCFeedParser使用一个NSURL属性来进行初始化，这个url可以获取RSS的订阅源（在这种情况下，一般会使用NSXMLParser和NSXMLParserDelegate来创建有意义的数据）。ZOCtableViewController通过一个ZOCFeedParser类来进行初始化。我们希望它可以通过“Parser”显示并复用这些值，并且我们使用以下协议进行委托：
我觉得这是一个完美又合理的协议来处理RSS。视图控制器将会在公共接口中实现它：
还有最终的实现代码像这样：
到目前为止都比较好，你也可能很高兴看到这样的代码，但是，这些代码有多少能被有效利用呢？视图控制器只可以处理ZOCFeedParser类型的对象：在这点上，我们只需将代码在不产生任何额外冗余代码的情况下拆解成两个组件，然后拆分开他们的责任。
视图控制器的责任应该是“显示列表并且知道谁提供数据”，但是我们却仅仅允许它传入ZOCfeedParser对象，这不能满足需求。这种情况下需要一个更通用的类型去作用于视图控制器。
我们修改了我们的“Feed Parser”，引入了 ZOCFeedParserProtocol 协议（在ZOCFeedParserProtocol.h文件中，其中还有 ZOCFeedParserDelegate）。
请注意，代理协议现在处理符合我们新协议的对象，还有ZOCFeedParser的接口文件也将变得更简洁：
由于ZOCFeedParser现在遵守ZOCFeedParserProtocol，它必须实现所有的@required的方法。此时，视图控制器可以接受所有遵守新协议的对象，确定对象将响应 start 和 stop 方法，并且这个新对象将通过代理属性提供信息。这是所有视图控制器应该知道的已经给定的对象，并且没有实现细节应该关注它。
上述代码似乎只是一个很小的变化，但实际上这是一个巨大的改进，因为视图控制器将针对协议而不是针对具体实现。这产生了很多优点：
* 视图控制器现在可以接受任何通过delegate属性提供某些信息的对象：这可以是一个RSS远端的源解析器，本地的一个，远程读取其他类型数据的服务，甚至可以是本地数据库获取数据的服务；
* 源解析器对象可以完全复用；
* ZOCFeedParser和ZOCFeedParserDelegate可以被其它组件复用；
* ZOCViewController（UI逻辑分开）可以被复用；
* 它更容易测试，因为可以使用遵守相应协议的模拟对象；
在执行协议时，你应该始终遵守 Liskov Substitution Principle。这个原则指出，你应该能够将一个接口的实现替换为另一个实现，并且不会破坏客户端或者实现。
换句话说，这意味着你的协议不应该暴露出具体实现类的细节；当通过你的协议设计抽象表达的时候要非常小心，并且记住底层实现是无关紧要的，真正重要的是抽象对象暴露给其他类的协议。
被设计出来重用的一切在将来会造就更好的代码，而且这应该是程序员的目标。以这种方式构建代码是有经验的程序员和新手之间的区别。
