objc是一门面向对象的语言，面向对象的封装继承多态也为我们带来了很多的便利。然而滥用的话很容易造成很多的坑，尤其是可能造成代码中很多的高耦合，组件很难被复用。举个工作中遇到的例子:
工作中开发的app中A界面有个输入框，会根据服务器上用户的输入历史来自动补全，叫AutoCompleteTextField。后来某天来了个需求：
在另外一个界面中，也用到这个输入框，除了根据输入历史补全，增加一个自动补全邮箱的功能，就是用户输入@后，我们自动补全一些域名。这个功能很简单，结构如下：
@interface AutoCompleteTextField : UITextField
- (void)autoCompleteWithUserInfo;
@end
@interface AutoCompleteMailTextField : AutoCompleteTextField
- (void)autoCompleteWithMail;
@end
过两天，产品经理希望有个本地输入框能够根据本地用户信息来补全，而不是根据服务器的信息来自动补全，我们可以轻松通过覆盖来实现：
@interface AutoCompleteLocalTextField : AutoCompleteTextField
- (void) autoCompleteWithUserInfo;
@end
目前来看一切顺利，每次功能实现也很简单。然而某一天，设计希望A界面的输入框样式做调整，而其他地方的 输入框样式保持不变。虽然有点蛋疼，但是我们还是可以从容的解决：添加个初始化函数initWithStyle。
相安无事又过了几天，突然有隔壁项目组的哥们想把我们的本地补全输入框AutoCompleteLocalTextField 移植到他们的项目中，这个时候真的就是个蛋疼的事情了。因为我们的基类AutoCompleteTextField中耦合了服务器请求解析的service逻辑代码，也就是说我们还要把网络请求部分的逻辑移植到别人的项目中，网络请求解析中可能还耦合了很多数据的model类型，这个真的就是个庞大的工程了。然而我们想要的只是一个很少功能的textfileld啊！
这时候就看出继承是有很大问题的：紧耦合！
不仅仅是这样的小控件，之前做的某个项目中，所有的ViewController都需要依赖一个BaseViewController，这样在实际开发中十分的不方便：
a.因为所有的contoller都需要依赖这个base，我们在开发某个功能时可能会先写个demo，那么在这个demo写好后，原本是希望这其中的代码可以直接移植到开发项目中的，然而做不到，因为基类与我们用的原生的viewcontoller有所不同。
b.这个基类BaseViewController会随着时间的推移，变得越来越不可控，很多逻辑不知道塞到哪里的最终可能都被塞到基类中，造成基类耦合很多的外部库，逻辑混乱，代码量越来越大。
回到刚才的例子中，如何解决这种继承的问题呢？很好的解决方案就是，用组合的方式。在ios中我们用代理可以轻松的实现：
@protocol CompleteDelegate <NSObject>
- (void)completeLogic;
@end
@interface AutoCompleteTextField : UITextField
@property (nonatomic, weak) id<CompleteDelegate> completeDelegate;
@end
另外，对于AutoCompleteMailTextField，AutoCompleteLocalTextField两个来说，个人认为也不应该作为AutoCompleteTextField的子类来写，毕竟complete是逻辑上完成的事。这里面可以做个XXTextField来作为基类，里面有些基本通用的样式布局逻辑，各种AutoTextField作为它的子类倒是可取，至于补全逻辑，还是放到协议中来写吧。代码上的改动只是一点点，然而思想大不同。
