OC中protocol、category和继承的区别以前还是有点迷糊，现在结合一些 资料总结一下。 利用继承，多态是一个很好的保持“对扩展开放、对更改封 闭”（OCP）的办法，也是最常见的一种方法。Objective C还支持另外两种语 法来支持OCP：Protocol和Category。Protocol只能定义一套接口，而不能提供实现，变相的也是一种Abstract class的实现方式（oc 语法上本身不支持抽象基类）。Category可以为类提供额外的接口和实现。那么到底三者（继承, Protocol，Category）在使用上到底有什么本质的区别呢？在我看来，protocol的作用是为一些列类仅仅提供一套公用的接口，而完全没 有办法也没可能去提供具体的一些实现情况；category则是为一个已有的类提供一些额外的接口和具体实现；而继承则基于两者之间，既可以想 protocol一样提供只是纯粹提供接口，也可以像Category一样提供完整的实现，而且继承还能对类以后的功能进行改写，所以说继承的力量是最强 大的。那么具体在使用的时候各自都适合什么样的情况呢？ .

Protocol是定义行为而不管谁去怎么实现，这是一种比较洒脱和不负责的情况，就好像在外包项目中的客户一样，他只是他需要什么什么东西，具体实现他不会也不能给出一样。delegate datasource这样的就用protocol实现比较好 .

Category是对一个功能完备的类的一种补充，就像是一个东西的主要基本功能都完成了，可以用category为这个类添加不同的组件，使得 这个类能够适应不同情况的需求（但是这些不同需求最核心的需求要一致）。找个就像你已经有了一辆能够开动的汽车一样，我们可以用Category为你的汽 车添加各种之前没有的功能，最后让这辆汽车变成超级跑车一样. 当某个类非常大的时候，Category可以按不同的功能将类的实现分在不同的模块中实现。

继承则是都可以完成上面的工作，但是继承有很大的代价问题，一是通过继承来进行扩展是一种耦合很高的行为，对父类可以说是完全依赖；二是继承由于 对父类依赖，所以开发代价相对大，要求对父类的工作流程相对熟悉；三是继承体系如果太复杂会导致整个系统混乱，难以维护。所以在能够用上面两种方法完成扩 展的时候，就千万不要使用继承。什么情况才是迫不得已要使用继承呢？那就是如果你既想提供一系列接口的定义，同时又想提供一些但是又不能提供全部的实现的 时候，这种情况就要使用继承了。所以这么看来继承是对上面两种功能的一个黏合剂。 关于category的另外一些见解： . 虽然category可以访问类的实例变量，去不能创建新的实例变量，如果要创新的实例变量，请使用继承； .

在category中，不提倡对原有方法进行重载。原因非常简单，在category中进行重载，无法对原方法进行访问，而继承中可以使用super。如果真的需要对原方法进行重载，请考虑继承，比如我要定义一个继承自UIViewController的类，就不能用Category，因为，这我定义的这个类中，我要实现UIViewController中的viewDidLoad、init等方法，用了category后父UIViewController中的这些方法将无法被调用一个类可以定义多个category，但是如果不同category中存在相同方法，编译器无法决定使用哪个category；

在定义category时，我们可以仅仅给出方法定义，而不需要给出具体的实现。这在程序增量开发时是非常有帮助的；category是可以被继承的。在某个父类中定义了category，那么他所有的子类都具有该category；在需要为某个类创建私有成员方法时，也用category的方式来实现。 Category不能完全代替子类，有以下几个最大的缺点： 当在Category中覆盖一个继承的方法，在Category中的方法可以通过向super类发送一个消息来调用被继承的方法。但是，如果Category中覆盖的那个方法已经在这个类的其它Category定义过了，则之前定义的方法将没有机会被程序调用 在Category中无法确定其能够可靠的覆盖某个方法，而这个方法已经在其它的Category中定义过。这个问题在使用Cocoa框架时尤其 突出。当你想覆盖某个框架已经定义好的方法时，该方法已经在其它Category中实现，这样就无法确定哪个定义和实现会被最先使用，带来很大的不确定 性。
.
如果你重新覆盖定义了一些方法，往往会导致这个方法在整个框架中实现发生了变化。举例来说，如果你增加了NSObject中 windowWillClose:的实现，这会导致所有的窗口调用那个新实现的方法，从而改变所有NSWindows实例的行为。这会带来很多不确定性， 并很有可能导致程序的崩溃