IOS 如何选择delegate、notification、KVO？

  前面分别讲了delegate、notification和KVO的实现原理，以及实际使用步骤，咱们心中不由有个疑问，他们的功能比较相似，那么在实际的编程中，如何选择这些方式呢？

       在网上看到一个博客上详细的分析了三者之间的区别以及各自的优点，博文地址为http://blog.shinetech.com/2011/06/14/delegation-notification-and-observation/，由于博文是用英文写的，下面将其翻译成中文。

        在开发ios应用的时候，咱们会常常遇到一个常见的问题：在不过度耦合的前提下，controllers间怎么进行通讯。在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

      缺点：

      1.须要定义不少代码：1.协议定义；2.controller的delegate属性；3.在delegate自己中实现delegate方法定义

      2.在释放代理对象时，须要当心的将delegate改成nil。一旦设定失败，那么调用释放对象的方法将会出现内存crash

      3.在一个controller中有多个delegate对象，而且delegate是遵照同一个协议，但仍是很难告诉多个对象同一个事件，不过有可能。

• notification

在IOS应用开发中有一个”Notification Center“的概念。它是一个单例对象，容许当事件发生时通知一些对象。它容许咱们在低程度耦合的状况下，知足控制器与一个任意的对象进行通讯的目的。这种模式的基本特征是为了让其余的对象可以接收到在该controller中发生某种事件而产生的消息，controller用一个key（通知名称）。这样对于controller来讲是匿名的，其余的使用一样的key来注册了该通知的对象（即观察者）可以对通知的事件做出反应。

        优点：

        1.不须要编写多少代码，实现比较简单；

        2.对于一个发出的通知，多个对象可以作出反应，即1对多的方式实现简单

        3.controller可以传递context对象（dictionary），context对象携带了关于发送通知的自定义的信息

        缺点：

        1.在编译期不会检查通知是否可以被观察者正确的处理； 

        2.在释放注册的对象时，须要在通知中心取消注册；

        3.在调试的时候应用的工做以及控制过程难跟踪；

        4.须要第三方对喜好那个来管理controller与观察者对象之间的联系；

        5.controller和观察者须要提早知道通知名称、UserInfo dictionary keys。若是这些没有在工做区间定义，那么会出现不一样步的状况；

        6.通知发出后，controller不能从观察者得到任何的反馈信息。

• KVO

KVO是一个对象可以观察另一个对象的属性的值，而且可以发现值的变化。前面两种模式更加适合一个controller与任何其余的对象进行通讯，而KVO更加适合任何类型的对象侦听另一个任意对象的改变（这里也能够是controller，但通常不是controller）。这是一个对象与另一个对象保持同步的一种方法，即当另一种对象的状态发生改变时，观察对象立刻做出反应。它只能用来对属性做出反应，而不会用来对方法或者动做做出反应。

        优势：

         1.可以提供一种简单的方法实现两个对象间的同步。例如：model和view之间同步；

         2.可以对非咱们建立的对象，即内部对象的状态改变做出响应，并且不须要改变内部对象（SKD对象）的实现；

         3.可以提供观察的属性的最新值以及先前值；

         4.用key paths来观察属性，所以也能够观察嵌套对象；

         5.完成了对观察对象的抽象，由于不须要额外的代码来容许观察值可以被观察

        缺点：

         1.咱们观察的属性必须使用strings来定义。所以在编译器不会出现警告以及检查；

         2.对属性重构将致使咱们的观察代码再也不可用；

         3.复杂的“IF”语句要求对象正在观察多个值。这是由于全部的观察代码经过一个方法来指向；

         4.当释放观察者时不须要移除观察者。

总结：

从上面的分析中能够看出3中设计模式都有各自的优势和缺点。其实任何一种事物都是这样，问题是如何在正确的时间正确的环境下选择正确的事物。下面就讲讲如何发挥他们各自的优点，在哪一种状况下使用哪一种模式。注意使用任何一种模式都没有对和错，只有更适合或者不适合。每一种模式都给对象提供一种方法来通知一个事件给其余对象，并且前者不须要知道侦听者。在这三种模式中，我认为KVO有最清晰的使用案例，并且针对某个需求有清晰的实用性。而另外两种模式有比较类似的用处，而且常常用来给controller间进行通讯。那么咱们在什么状况使用其中之一呢？

根据我开发iOS应用的经历，我发现有些过度的使用通知模式。我我的不是很喜欢使用通知中心。我发现用通知中心很难把握应用的执行流程。UserInfo dictionaries的keys处处传递致使失去了同步，并且在公共空间须要定义太多的常量。对于一个工做于现有的项目的开发者来讲，若是过度的使用通知中心，那么很难理解应用的流程。

我以为使用命名规则好的协议和协议方法定义对于清晰的理解controllers间的通讯是很容易的。努力的定义这些协议方法将加强代码的可读性，以及更好的跟踪你的app。代理协议发生改变以及实现均可经过编译器检查出来，若是没有将会在开发的过程当中至少会出现crash，而不只仅是让一些事情异常工做。甚至在同一事件通知多控制器的场景中，只要你的应用在controller层次有着良好的结构，消息将在该层次上传递。该层次可以向后传递直至让全部须要知道事件的controllers都知道。

固然会有delegation模式不适合的例外状况出现，并且notification可能更加有效。例如：应用中全部的controller须要知道一个事件。然而这些类型的场景不多出现。另一个例子是当你创建了一个架构并且须要通知该事件给正在运行中应用。

根据经验，若是是属性层的时间，无论是在不须要编程的对象仍是在牢牢绑定一个view对象的model对象，我只使用观察。对于其余的事件，我都会使用delegate模式。若是由于某种缘由我不能使用delegate，首先我将估计个人app架构是否出现了严重的错误。若是没有错误，而后才使用notification。

PS：翻译很差，请指正。