iOS 继承的深入探讨
继承
继承从代码复用的角度来说，特别好用，也特别容易被滥用和被错用。不恰当地使用继承导致的最大的一个缺陷特征就是高耦合。
在这里我要补充一点，耦合是一个特征，虽然大部分情况是缺陷的特征，但是当耦合成为需求的时候，耦合就不是缺陷了。
适用继承的场合
大神Chris Eidhof的文章《subclassing》提到需要自定义UITableViewCell等View视图的时候我们可以使用继承来创建自定义View,这些代码放入子类更合理，不光代码得到更好的封装，也能得到一个可以在工程中重用的组件。Chris Edihof还提到model可以继承来实现了 isEqual: 、hash 、 copyWithZone: 和 description 等方法的类。
当我们使用继承的时候我们需要考虑
- 父类只是给子类提供服务，并不涉及子类的业务逻辑
- 层级关系明显，功能划分清晰，父类和子类各做各的。
- 父类的所有变化，都需要在子类中体现，也就是说此时耦合已经成为需求
- 我们不能脱离cocoa框架开发，所以我们可以继承cocoa的类，以达到快速开发的目的，但是如果没有特殊原因我们写的代码要控制在继承链不增加两层。
不适合继承的场景
- 当你发现你的继承超过2层的时候，你就要好好考虑是否这个继承的方案了
- 不满足上面一些条件时候
替代继承解决复用需求的解决方案
对于这样的问题，业界其实早就给出了解决方案：用组合替代继承，通过定义好的接口进行交互，一般来说可以选择Delegate模式来交互。
协议
两个类并没有太多共用的代码，它们只不过具有相同的接口。如果这样的话，使用协议可能会是更好的方案
举个例子~
假设一个APP有播放器（player）对象，它拥有播放（play）方法播放视频，如果APP希望支持YouTube，需要相同几个播放（player）接口，
使用继承实现代码如下
<pre>
@interface Player : NSObject
- (void)play;
- (void)pause;
@end
@interface YouTubePlayer : Player
@end
</pre>
使用协议方法代码如下
<pre>
@protocol VideoPlayer <NSObject>
- (void)play;
- (void)pause;
@end
@interface Player : NSObject <VideoPlayer>
@end
@interface YouTubePlayer : NSObject <VideoPlayer>
@end
</pre>
代理
如果当我们类中的方法需要些自定义的行为时候，我们可以使用代理优雅解决这个实现
举个例子~
再以上面的例子为例，player对象希望在播放的时候执行一些自定义的行为，使用继承也可以轻易的实现：创建个player对象的子类，然后重写play方法，再调用[super play]，再跟着希望执行的行为。但是我们也可以通过的代理的方式更有优雅的实现这个需求
<pre>
@class Player;
@protocol PlayerDelegate
- (void)playerDidStartPlaying:(Player *)player;
@end
@interface Player : NSObject
@property (nonatomic,weak) id<PlayerDelegate> delegate;
- (void)play;
- (void)pause;
@end
</pre>
现在在player对象的play方法里，我们可以通过代理属性调用 playerDidStartPlaying：方法，任何使用Player类的对象，可以遵守代理协议，就可以实现自定义的playerDidStartPlaying：方法了，player类依然保持它的通用性和独立性，方便为对外提供服务。代理是非常强大技巧，苹果本身就经常使用。像 UITextField这样的类，有时候你还会想把几个不同的方法分组到几个单独的协议里，比如UITableView—— 它不仅有一个代理（delegate），还有一个数据源（dataSource）。
类别
我们有时候会给对象添加方法，通过继承的方式当然可以实现，但是不如category的方式来的方便和容易使用，不增加新的类，可复用的价值也更高
注意：
1> 在用类别扩展一个不是你自己的类的时候，在方法前添加前缀是个比较好的习惯做法。如果不这么做，有可能别人也用类别对此类添加了相同名字的函数。那时候程序的行为可能跟你想要的并不一样，未预期的事情可能会发生。
2> 使用类别还有另外一个风险，那就是，到最后你可能会使用一大堆的类别，连你自己都会失去对代码全局的认识。假如那样的话，创建自定义的类可能更简单一些。
组合
Casa提到我们尽可能用组合替代继承。组合是最强大的替代继承的选项。如果你想复用已经存在的代码，并且不想共享同样的接口，组合是最佳选择
举个例子~
假设你要设计一个缓存类
<pre>
@interface OBJCache : NSObject
- (void)cacheValue:(id)value forKey:(NSString *)key;
- (void)removeCachedValueForKey:(NSString *)key;
@end
</pre>
一个简单的做法就通过继承NSDictionary并且通过调用字典的方法来实现这上面两个缓存方法。
<pre>
@interface OBJCache : NSDictionary
</pre>
但是这样做会带来一些问题。它本来是应该被详细实现的，但只是通过字典来实现。现在，在任何需要一个 NSDictionary 参数的时候，你可以直接提供一个 OBJCache 值。但如果你想把它转为其它完全不同的东西（例如你自己的库），你就可能需要重构很多代码了。
更好的方式就是组合了。创建一个缓存类，并将添加一个字典的私有属性，对外还是暴露着两个接口，实现的时候就可以通过调用字典属性的方法实现我们使用字典的方法了，这样做可以灵活改变其涉嫌，而该类的使用者就不用进行重构。
总结
代码复用，尽管他们都可以通过继承实现，但是我们为了在没有耦合需求的时候尽量不要使用继承，而是根据不同场景采用不同复用代码的方式。如果只是共享接口，我们可以使用协议；如果是希望共用一个方法的部分实现，但希望根据需要执行不同的其他行为，我们可以使用代理；如果是添加方法，我们可以优先使用类别（category）；如果是为了使用一个类的很多方法，我们可以使用组合来实现。，如果当初只是出于代码复用的目的而不区分类别和场景，就采用继承是不恰当的。当你发现你的继承超过2层的时候，你就要好好考虑是否这个继承的方案了，第三层继承正是滥用的开端。确定有必要之后，再进行更多层次的继承。我认同Casa的看法：万不得已不要用继承，优先考虑组合等方式。
