iOS中如何选择delegate、通知、KVO（以及三者的区别）
转载自：http://blog.csdn.net/dqjyong/article/details/7685933
在开发IOS应用的时候，我们会经常遇到一个常见的问题：在不过分耦合的前提下，controllers[B]怎么进行通信。在IOS应用不断的出现三种模式来实现这种通信：
1委托delegation
2通知中心Notification Center
3键值观察key value observing，KVO
因此，那为什么我们需要这些模式以及什么时候用它以及什么时候不用它。
下面完全根据我的开发经验来讨论这三中模式。我将讨论为什么我觉得某种模式要好于另外一种模式以及为什么我觉得在一定的环境下某中模式比较好。我给出的这些原因并不是圣经，而仅仅是个人观点。如果你有什么不同的观点或者还可以进行补充的地方，可以联系我，一起讨论。
上面的三种模式是什么？
三种模式都是一个对象传递事件给另外一个对象，并且不要他们有耦合。三种模式都是对象来通知某个事件发生了的方法，或者更准确的说，是允许其他的对象收到这种事件的方法。这对于一个对象来说，是非常普通而且必须做的任务，因为没有通信，controllers将不能整合到整个应用中。controller的另外一个目的是尽可能的自包含。
我们希望controllers以自己的方式存在，在controllers屡面上不能与其他的controllers进行耦合。Controllers能够创建其他的controllers而且他们之间可以自由通信，但是我们不希望controller又回接到创建自己的controller。如果我们耦合了他们，那么我们将不能复用他们，以及完全失去对应用中一个独立的组件的控制。
这三种模式给controllers(也可以是其他的对象)提供通信的方法。下面将描述如何在IOS应用中使用这些模式同样需要注意的他们在其他的地方也会用到，并且确实是存在。
. delegation
当我们第一次编写IOS应用时，我们注意到不断的在使用“delegate"，并且贯穿于整个SDK。delegation模式不是IOS特有的模式，而是依赖与你过去拥有的编程背景。针对它的优势以及为什么经常使用到，这种模式可能不是很明显的。
delegation的基本特征是，一个controller定义了一个协议（即一系列的方法定义）。该协议描述了一个delegate对象为了能够响应一个controller的事件而必须做的事情。协议就是delegator说，“如果你想作为我的delegate，那么你就必须实现这些方法”。实现这些方法就是允许controller在它的delegate能够调用这些方法，而它的delegate知道什么时候调用哪种方法。delegate可以是任何一种对象类型，因此controller不会与某种对象进行耦合，但是当该对象尝试告诉委托事情时，该对象能确定delegate将响应。
三者优缺点：
delegate 的 优势 ：
1.非常严格的语法。所有将听到的事件必须是在delegate协议中有清晰的定义。
2.如果delegate中的一个方法没有实现那么就会出现编译警告/错误
3.协议必须在controller的作用域范围内定义
4.在一个应用中的控制流程是可跟踪的并且是可识别的；
5.在一个控制器中可以定义定义多个不同的协议，每个协议有不同的delegates
6.没有第三方对象要求保持/监视通信过程。
7.能够接收调用的协议方法的返回值。这意味着delegate能够提供反馈信息给controller
8.经常被用在存在父子关系的对象之间通信，例如控制器和控制器的view（自己加的理解）
缺点 ：
1.需要定义很多代码：1.协议定义；2.controller的delegate属性；3.在delegate本身中实现delegate方法定义
2.在释放代理对象时，需要小心的将delegate改为nil。一旦设定失败，那么调用释放对象的方法将会出现内存crash
3.在一个controller中有多个delegate对象，并且delegate是遵守同一个协议，但还是很难告诉多个对象同一个事件，不过有可能。
4.经常用在一对一的通信。（不知道是缺点还是优点，只能算是特点）（自己加的理解）
notification 的 优势 ：
1.不需要编写多少代码，实现比较简单
2.对于一个发出的通知，多个对象能够做出反应，即一对多的方式实现简单
3.controller能够传递context对象（dictionary），context对象携带了关于发送通知的自定义的信息
缺点 ：
1.在编译期不会检查通知是否能够被观察者正确的处理；
2.在释放注册的对象时，需要在通知中心取消注册；
3.在调试的时候应用的工作以及控制过程难跟踪；
4.需要第三方对象来管理controller与观察者对象之间的联系；
5.controller和观察者需要提前知道通知名称、UserInfo dictionary keys。如果这些没有在工作区间定义，那么会出现不同步的情况；
6.通知发出后，controller不能从观察者获得任何的反馈信息（相比较delegate）。
KVO 的 优势 ：
1.能够提供一种简单的方法实现两个对象间的同步。例如：model和view之间同步；
2.能够对非我们创建的对象，即内部对象的状态改变作出响应，而且不需要改变内部对象（SKD对象）的实现；
3.能够提供观察的属性的最新值以及先前值；
4.用key paths来观察属性，因此也可以观察嵌套对象；
5.完成了对观察对象的抽象，因为不需要额外的代码来允许观察值能够被观察
6.可以一对多。
缺点 ：
1.我们观察的属性必须使用strings来定义。因此在编译器不会出现警告以及检查；
2.对属性重构将导致我们的观察代码不再可用；
3.复杂的“IF”语句要求对象正在观察多个值。这是因为所有的观察代码通过一个方法来指向；
4.当释放观察者时不需要移除观察者。
1. 效率 肯定是delegate比NSNotification高。
delegate方法比notification更加直接，最典型的特征是，delegate方法往往需要关注返回值， 也就是delegate方法的结果。比如-windowShouldClose:，需要关心返回的是yes还是no。所以delegate方法往往包含 should这个很传神的词。也就是好比你做我的delegate，我会问你我想关闭窗口你愿意吗？你需要给我一个答案，我根据你的答案来决定如何做下一 步。相反的，notification最大的特色就是不关心接受者的态度， 我只管把通告放出来，你接受不接受就是你的事情，同时我也不关心结果。所以notification往往用did这个词汇，比如 NSWindowDidResizeNotification，那么NSWindow对象放出这个notification后就什么都不管了也不会等待接 受者的反应。
2、KVO和NSNotification的区别 ：
和delegate一样，KVO和NSNotification的作用也是类与类之间的通信，与delegate不同的是1）这两个都是负责发出通知，剩下的事情就不管了，所以没有返回值；2）delegate只是一对一，而这两个可以一对多。这两者也有各自的特点。
总结：
从上面的分析中可以看出3中设计模式都有各自的优点和缺点。其实任何一种事物都是这样，问题是如何在正确的时间正确的环境下选择正确的事物。下面就讲讲如何发挥他们各自的优势，在哪种情况下使用哪种模式。注意使用任何一种模式都没有对和错，只有更适合或者不适合。每一种模式都给对象提供一种方法来通知一个事件给其他对
象，而且前者不需要知道侦听者。在这三种模式中，我认为KVO有最清晰的使用案例，而且针对某个需求有清晰的实用性。而另外两种模式有比较相似的用处，并且经常用来给controller间进行通信。那么我们在什么情况使用其中之一呢？
根据我开发iOS应用的经历，我发现有些过分的使用通知模式。我个人不是很喜欢使用通知中心。我发现用通知中心很难把握应用的执行流程。Userlnfo dictionaries的keys到处传递导致失去了同步，而且在公共空间需要定义太多的常量。对于一个工作于现有的项目的开发者来说，如果过分的使用通知中心，那么很难理解应用的流程。
我觉得使用命名规则好的协议和协议方法定义对于清晰的理解controllers间的通信是很容易的。努力的定义这些协议方法将增强代码的可读性，以及更好的跟踪你的app。代理协议发生改变以及实现都可通过编译器检查出来，如果没有将会在开发的过程中至少会出现crash，而不仅仅是让一些事情异常工作。甚至在同一事件通知多控制器的场景中，只要你的应用在controller层次有着良好的结构，消息将在该层次上传递。该层次能够向后传递直至让所有需要知道事件的controllers都知道。当然会有delegation模式不适合的例外情况出现，而且notification可能更加有效。例如：应用中所有的controller需要知道一个事件。然而这些类型的场景很少出现。另外一个例子是当你建立了一个架构而且需要通知该事件给正在运行中应用。
根据经验，如果是属性层的时间，不管是在不需要编程的对象还是在紧紧绑定一个view对象的model对象，我只使用观察。对于其他的事件，我都会使用delegate模式。如果因为某种原因我不能使用delegate，首先我将估计我的app架构是否出现了严重的错误。如果没有错误，然后才使用notification。
