OC学习小结之protocol

一、协议是什么

Protocol只能定义一套接口，而不能提供实现，变相的也是一种Abstract class的实现方式（oc 语法上本身不支持抽象基类），

它的作用为一些列类仅仅提供一套公用的接口，而完全没 有办法也没可能去提供具体的一些实现情况。

二、协议的使用

1）协议的定义。

@protocol 协议名称  <继承协议1，集成协议2，。。。>

@optional／／可以不实现下面方法

方法

@required ／／遵守该协议必须实现下面方法

方法

@end

2）协议的实现。

@interface 类名 ：父类名<遵守协议名，。。。>／／该类中遵守的协议名称

@end

3）协议的调用。

名<协议名称> *变量名;

id<协议名称> 变量名;

三、protocol 、catergory 和继承（from wuyutaott 的博客）

• Protocol是定义行为而不管谁去怎么实现，这是一种比较洒脱和不负责的情况，就好像在外包项目中的客户一样，他只是他需要什么什么东西，具体实现他不会也不能给出一样。delegate datasource这样的就用protocol实现比较好
• Category是对一个功能完备的类的一种补充，就像是一个东西的主要基本功能都完成了，可以用category为这个类添加不同的组件，使得 这个类能够适应不同情况的需求（但是这些不同需求最核心的需求要一致）。找个就像你已经有了一辆能够开动的汽车一样，我们可以用Category为你的汽 车添加各种之前没有的功能，最后让这辆汽车变成超级跑车一样。
• 当某个类非常大的时候，Category可以按不同的功能将类的实现分在不同的模块中实现。
• 继承则是都可以完成上面的工作，但是继承有很大的代价问题，一是通过继承来进行扩展是一种耦合很高的行为，对父类可以说是完全依赖；二是继承由于 对父类依赖，所以开发代价相对大，要求对父类的工作流程相对熟悉；三是继承体系如果太复杂会导致整个系统混乱，难以维护。所以在能够用上面两种方法完成扩 展的时候，就千万不要使用继承。什么情况才是迫不得已要使用继承呢？那就是如果你既想提供一系列接口的定义，同时又想提供一些但是又不能提供全部的实现的 时候，这种情况就要使用继承了。所以这么看来继承是对上面两种功能的一个黏合剂。