适用继承的场合

      大神Chris Eidhof的文章《subclassing》提到需要自定义UITableViewCell等View视图的时候我们可以使用继承来创建自定义View,这些代码放入子类更合理，不光代码得到更好的封装，也能得到一个可以在工程中重用的组件。Chris Edihof还提到model可以继承来实现了 isEqual: 、hash 、 copyWithZone: 和 description 等方法的类。

Chris Eidhof说的只是继承的几个应用场景，他没有说使用继承的界限。 Casa还提到是否使用继承需要考虑三个点：

1. 父类只是给子类提供服务，并不涉及子类的业务逻辑

2. 层级关系明显，功能划分清晰，父类和子类各做各的。

3. 父类的所有变化，都需要在子类中体现，也就是说此时耦合已经成为需求

　　在我看来一个很重要的原则就是我们不能脱离cocoa框架开发，所以我们可以继承cocoa的类，以达到快速开发的目的，但是如果没有特殊原因我们写的代码要控制在继承链不增加两层。

不适合继承的场景

我比较同意Casa的观点。当你发现你的继承超过2层的时候，你就要好好考虑是否这个继承的方案了，第三层继承正是滥用的开端。确定有必要之后，再进行更多层次的继承。Chris Eidhof也有类似的观点：In a lot of projects that I’ve worked on, I’ve seen deep hierarchies of subclasses. I am guilty of doing this as well. Unless the hierarchies are very shallow, you very quickly tend to hit limits. 在我工作的许多项目中看到过一些深度继承的项目。当我也这么干的时候，总会感到内疚。除非继承的层次非常浅，否则你会很快发现它的局限性。

替代继承解决复用需求的解决方案

      1.协议（protocols）

　　我经常使用继承来使得对象能够响应某个方法，假设一个APP有播放器（player）对象，它拥有播放（play）方法播放视频，如果APP希望支持YouTube，需要相同几个播放（player）接口，但是方法的实现不同，通过继承实现的代码如下：

@interface Player : NSObject

- (void)play;

- (void)pause;
 
@end

@interface YouTubePlayer : Player


@end

　　这两个类并没有太多共用的代码，它们只不过具有相同的接口。如果这样的话，使用协议可能会是更好的方案。可以这样用协议来写你的代码。

@protocol VideoPlayer <NSObject>

- (void)play;
- (void)pause;

@end


@interface Player : NSObject <VideoPlayer>

@end


@interface YouTubePlayer : NSObject <VideoPlayer>

@end

　　这样，YouTubePlayer 类就不必知道 Player 类的内部实现了。

      2.代理（delegation）            

再以上面的例子为例，player对象希望在播放的时候执行一些自定义的行为，使用继承也可以轻易的实现：创建个player对象的子类，然后重写play方法，再调用[super play]，再跟着希望执行的行为。但是我们也可以通过的代理的方式更有优雅的实现这个需求：

@class Player;

@protocol PlayerDelegate

- (void)playerDidStartPlaying:(Player *)player;

@end


@interface Player : NSObject

@property (nonatomic,weak) id<PlayerDelegate> delegate;

- (void)play;
- (void)pause;

@end

　　现在在player对象的play方法里，我们可以通过代理属性调用 playerDidStartPlaying：方法，任何使用Player类的对象，可以遵守代理协议，就可以实现自定义的playerDidStartPlaying：方法了，player类依然保持它的通用性和独立性，方便为对外提供服务。代理是非常强大技巧，苹果本身就经常使用。像 UITextField 这样的类，有时候你还会想把几个不同的方法分组到几个单独的协议里，比如UITableView —— 它不仅有一个代理（delegate），还有一个数据源（dataSource）。

　　3.类别（category）

　　我们有时候会给对象添加方法，通过集成的方式当然可以实现，但是不如category的方式来的方便和容易使用，不增加新的类，可复用的价值也更高。 比如我们需要给NSArray添加一个arrayByRemovingFirstObject方法，通过category的方式我们就可以这么做：

@interface NSArray (OBJExtras)

- (void)obj_arrayByRemovingFirstObject;

@end

　　在用类别扩展一个不是你自己的类的时候，在方法前添加前缀是个比较好的习惯做法。如果不这么做，有可能别人也用类别对此类添加了相同名字的函数。那时候程序的行为可能跟你想要的并不一样，未预期的事情可能会发生。

　　使用类别还有另外一个风险，那就是，到最后你可能会使用一大堆的类别，连你自己都会失去对代码全局的认识。假如那样的话，创建自定义的类可能更简单一些。

　　4.组合（composition）

　　Casa提到我们尽可能用组合替代继承。组合是最强大的替代组合的选项。如果你想复用已经存在的代码，并且不想共享同样的接口，组合是最佳选择。举个例子，假设你要设计一个缓存类：

@interface OBJCache : NSObject

- (void)cacheValue:(id)value forKey:(NSString *)key;
- (void)removeCachedValueForKey:(NSString *)key;

@end

　　一个简单的做法就通过聚成NSDictionary并且通过调用字典的方法来实现这上面两个缓存方法。

@interface OBJCache : NSDictionary

　　但是这样做会带来一些问题。它本来是应该被详细实现的，但只是通过字典来实现。现在，在任何需要一个 NSDictionary 参数的时候，你可以直接提供一个 OBJCache 值。但如果你想把它转为其它完全不同的东西（例如你自己的库），你就可能需要重构很多代码了。

　　更好的方式就是组合了。创建一个缓存类，并将添加一个字典的私有属性，对外还是暴露着两个接口，实现的时候就可以通过调用字典属性的方法实现我们使用字典的方法了，这样做可以灵活改变其涉嫌，而该类的使用者恩不用进行重构。

总结

　　代码复用，尽管他们都可以通过继承实现，但是我们为了在没有耦合需求的时候尽量不要使用继承，而是根据不同场景采用不同复用代码的方式。如果只是共享接口，我们可以使用协议；如果是希望共用一个方法的部分实现，但希望根据需要执行不同的其他行为，我们可以使用代理；如果是添加方法，我们可以优先使用类别（category）；如果是为了使用一个类的很多方法，我们可以使用组合来实现。，如果当初只是出于代码复用的目的而不区分类别和场景，就采用继承是不恰当的。当你发现你的继承超过2层的时候，你就要好好考虑是否这个继承的方案了，第三层继承正是滥用的开端。确定有必要之后，再进行更多层次的继承。我认同Casa的看法：万不得已不要用继承，优先考虑组合等方式。

• 上一篇基于react-router的单页应用