controllers间通信－delegate、Notification、KVO比较

在不过分耦合的前提下，controllers间怎么进行通信。在IOS应用不断的出现三种模式来实现这种通信：
1.委托delegate；
2.通知中心Notification Center；
3.键值观察key value observing，KVO

delegate
优势
1.要委托的事件要在delegate协议中有定义
2.如果delegate中的方法没有实现，就会出现编译警告
3.协议在Controller的作用域范围内定义
4.在一个应用中可以控制和跟踪
5.在一个控制器中可以定义多个不同的delegate
6.能够接受调用的协议方法的返回值，
缺点
1.需要定义很多代码，定义协议，在委托者中定义委托方法，设置被委托者的delegate
2.在释放代理对象时，需要小心的将delegate改为nil。一旦设定失败，那么调用释放对象的方法将会出现内存crash
3.在一个controller中有多个delegate对象，并且delegate是遵守同一个协议，但还是很难告诉多个对象同一个事件，不过有可能。

Notification
优势
1.不需要写很多代码，实现比较简单
2.发出一个通知，多个对象能够接受，即实现了一对多的实现简单
3.controller能够传递context对象（dictionary），context对象携带了关于发送通知的自定义的信息
缺点
1.观察者需要提前知道通知的名称、UserInfo dictionary keys等信息
2.通知发出后，不能从观察者获得反馈信息
3.在编译器不会检查通知是否能够被观察者正确的处理
4.调试时，难以跟踪和控制

KVO
优势
1.能够提供一种简单的方法实现两个对象的同步，例如model和view之间的同步
2.能够观察属性的最新值以及旧值，可以使用key paths观察嵌套对象
3.能够对非我们创建的对象，即内部对象的状态改变作出响应，而且不需要改变内部对象（SKD对象）的实现；
缺点：
1.我们观察的属性必须使用strings来定义。因此在编译器不会出现警告以及检查；
2.对属性重构将导致我们的观察代码不再可用；

在这三种模式中，我认为KVO有最清晰的使用案例，而且针对某个需求有清晰的实用性。而另外两种模式有比较相似的用处，并且经常用来给controller间进行通信。那么我们在什么情况使用其中之一呢？

根据我开发iOS应用的经历，我发现有些过分的使用通知模式。我个人不是很喜欢使用通知中心。我发现用通知中心很难把握应用的执行流程。UserInfo dictionaries的keys到处传递导致失去了同步，而且在公共空间需要定义太多的常量。对于一个工作于现有的项目的开发者来说，如果过分的使用通知中心，那么很难理解应用的流程。
我觉得使用命名规则好的协议和协议方法定义对于清晰的理解controllers间的通信是很容易的。努力的定义这些协议方法将增强代码的可读性，以及更好的跟踪你的app。代理协议发生改变以及实现都可通过编译器检查出来，如果没有将会在开发的过程中至少会出现crash，而不仅仅是让一些事情异常工作。甚至在同一事件通知多控制器的场景中，只要你的应用在controller层次有着良好的结构，消息将在该层次上传递。该层次能够向后传递直至让所有需要知道事件的controllers都知道。

参考：http://blog.csdn.net/dqjyong/article/details/7685933