对于一些差异不大的，复用是很好；但是有些看起来貌似可以复用，但是里面的逻辑（或者说if，else等）很多的这时不建议复用，因为耦合度太高，并且不好修改和后期维护。
ps:
runtime依赖
使用runtime来处理耦合是Objective C独特的方式，而且耦合度非常之低，甚至可以说感觉不到耦合的存在，比如：
//Person.m
- (void)drink:(id)obj
{
id water = nil;
SEL sel = NSSelectorFromString(@"provideWater");
if ([obj respondsToSelector:sel]) {
water = [obj performSelector:sel];
}
if (water) {
[self sip:water];
}
}
既不需要导入Cup的头文件，也不需要知道Cup到底支持哪些方法。这种方式的问题也正是由于耦合度太低了，让开发者感知不到耦合的存在，感知不到类之间的关系。如果哪天有人把provideWater改写成getWater，drink方法如果没有同步到，Xcode编译时不会提示你，runtime也不会crash，但是业务流程却没有正常往下走了。
这也是为什么我们不推荐用Objective-C runtime的黑魔法去做业务，只是在无副作用的场景下去完成一些数据的获取操作，比如使用AOP去log日志。
protocol依赖
这并不是一种独立的耦合方式，protocol可以结合上述各种耦合方式来进一步降低耦合，也是在复杂类关系设计中推荐的方式，比如我们可以定义这样一个protocol：
@protocol LiquidContainer <NSObject>
- (id)provideWater;
- (id)provideCoffee;
@end
//Person.h
@interface Person : NSObject
- (void)drink:(id<LiquidContainer>)container;
@end
上述的方式中，无论是Property持有还是parameter注入，都可以使用protocol来降低依赖，protocol的好处在于他只规定了方法的声明，并不限定具体是那个类来实现它，给后期的维护留下更大的空间和可能性。
个人总结，protocol的这种解耦性，也是为什么那么多的第三方，喜欢用protocol的原因。
