delegate、notification既荚、KVO 區(qū)別

在開發(fā)ios應(yīng)用的時(shí)候，我們會(huì)經(jīng)常遇到一個(gè)常見的問題：在不過分耦合的前提下恰聘，controllers間怎么進(jìn)行通信。在iOS應(yīng)用不斷的出現(xiàn)三種模式來實(shí)現(xiàn)這種通信：

    1.委托delegate； 特點(diǎn)一對(duì)一

    2.通知中心Notification Center晴叨； 特點(diǎn)一對(duì)多

    3.鍵值觀察key value observing凿宾，KVO 特點(diǎn)一對(duì)一

     三種模式都是一個(gè)對(duì)象傳遞事件給另外一個(gè)對(duì)象兼蕊，并且不要他們有耦合。三種模式都是對(duì)象來通知某個(gè)事件發(fā)生了的方法遍略，或者更準(zhǔn)確的說惧所，是允許其他的對(duì)象收到這種事件的方法。這對(duì)于一個(gè)對(duì)象來說绪杏，是非常普通而且必須做的任務(wù)下愈，因?yàn)闆]有通信，controllers將不能整合到整個(gè)應(yīng)用中势似。controller的另外一個(gè)目的是盡可能的自包含僧著。我們希望controllers以自己的方式存在履因，在controllers層面上不能與其他的controllers進(jìn)行耦合盹愚。Controllers能夠穿件其他的controllers而且他們之間可以自由通信，但是我們不希望controller又回接到創(chuàng)建自己的controller毅舆。如果我們耦合了他們，那么我們將不能復(fù)用他們愈腾，以及完全失去對(duì)應(yīng)用中一個(gè)獨(dú)立的組件的控制。

    這三種模式給controllers(也可以是其他的對(duì)象）提供通信的方法悦即。下面將描述如何在ios應(yīng)用中使用這些模式橱乱，同樣需要注意的他們?cè)谄渌牡胤揭矔?huì)用到辜梳，并且確實(shí)是存在仅醇。

delegate

   delegate的優(yōu)勢(shì)：
  1.非常嚴(yán)格的語法。所有將聽到的事件必須是在delegate協(xié)議中有清晰的定義;
  2.如果delegate中的一個(gè)方法沒有實(shí)現(xiàn)那么就會(huì)出現(xiàn)編譯警告/錯(cuò)誤;
  3.協(xié)議必須在controller的作用域范圍內(nèi)定義;
  4.在一個(gè)應(yīng)用中的控制流程是可跟蹤的并且是可識(shí)別的粉洼；
  5.在一個(gè)控制器中可以定義定義多個(gè)不同的協(xié)議，每個(gè)協(xié)議有不同的delegates;
  6.沒有第三方對(duì)象要求保持/監(jiān)視通信過程;
  7.能夠接收調(diào)用的協(xié)議方法的返回值属韧。這意味著delegate能夠提供反饋信息給controller.
  缺點(diǎn)：
  1.需要定義很多代碼：1.協(xié)議定義；2.controller的delegate屬性宵喂；3.在delegate本身中實(shí)現(xiàn)delegate方法定義
  2.weak作為屬性修飾符；
  3.在一個(gè)controller中有多個(gè)delegate對(duì)象拙泽，并且delegate是遵守同一個(gè)協(xié)議，但還是很難告訴多個(gè)對(duì)象同一個(gè)事件顾瞻，不過有可能德绿。

notification

在IOS應(yīng)用開發(fā)中有一個(gè)Notification Center的概念。它是一個(gè)單例對(duì)象移稳，允許當(dāng)事件發(fā)生時(shí)通知一些對(duì)象。它允許我們?cè)诘统潭锐詈系那闆r下个粱，滿足控制器與一個(gè)任意的對(duì)象進(jìn)行通信的目的。這種模式的基本特征是為了讓其他的對(duì)象能夠接收到在該controller中發(fā)生某種事件而產(chǎn)生的消息都许，controller用一個(gè)key（通知名稱）。這樣對(duì)于controller來說是匿名的，其他的使用同樣的key來注冊(cè)了該通知的對(duì)象（即觀察者）能夠?qū)νㄖ氖录鞒龇磻?yīng)絮吵。

    優(yōu)勢(shì)：
    1.不需要編寫多少代碼，實(shí)現(xiàn)比較簡(jiǎn)單蹬敲；
    2.對(duì)于一個(gè)發(fā)出的通知，多個(gè)對(duì)象能夠做出反應(yīng)急波，即1對(duì)多的方式實(shí)現(xiàn)簡(jiǎn)單;
    3.controller能夠傳遞context對(duì)象（dictionary）瘪校，context對(duì)象攜帶了關(guān)于發(fā)送通知的自定義的信息.
    缺點(diǎn)：
    1.在編譯期不會(huì)檢查通知是否能夠被觀察者正確的處理澄暮； 
    2.在釋放注冊(cè)的對(duì)象時(shí)，需要在通知中心取消注冊(cè)伸辟；
    3.在調(diào)試的時(shí)候應(yīng)用的工作以及控制過程難跟蹤馍刮；
    4.需要第三方對(duì)喜愛那個(gè)來管理controller與觀察者對(duì)象之間的聯(lián)系信夫；
    5.controller和觀察者需要提前知道通知名稱卡啰、UserInfo dictionary keys。如果這些沒有在工作區(qū)間定義振湾，那么會(huì)出現(xiàn)不同步的情況；
    6.通知發(fā)出后恰梢，controller不能從觀察者獲得任何的反饋信息梗掰。

KVO

KVO是一個(gè)對(duì)象能夠觀察另外一個(gè)對(duì)象的屬性的值嵌言，并且能夠發(fā)現(xiàn)值的變化及穗。前面兩種模式更加適合一個(gè)controller與任何其他的對(duì)象進(jìn)行通信，而KVO更加適合任何類型的對(duì)象偵聽另外一個(gè)任意對(duì)象的改變（這里也可以是controller苛白，但一般不是controller）。這是一個(gè)對(duì)象與另外一個(gè)對(duì)象保持同步的一種方法购裙，即當(dāng)另外一種對(duì)象的狀態(tài)發(fā)生改變時(shí)鹃栽，觀察對(duì)象馬上作出反應(yīng)。它只能用來對(duì)屬性作出反應(yīng)民鼓，而不會(huì)用來對(duì)方法或者動(dòng)作作出反應(yīng)。

    優(yōu)點(diǎn)：
     1.能夠提供一種簡(jiǎn)單的方法實(shí)現(xiàn)兩個(gè)對(duì)象間的同步丰嘉。例如：model和view之間同步；
     2.能夠?qū)Ψ俏覀儎?chuàng)建的對(duì)象耍贾，即內(nèi)部對(duì)象的狀態(tài)改變作出響應(yīng)，而且不需要改變內(nèi)部對(duì)象（SKD對(duì)象）的實(shí)現(xiàn)逼争；
     3.能夠提供觀察的屬性的最新值以及先前值；
     4.用key paths來觀察屬性誓焦，因此也可以觀察嵌套對(duì)象；
     5.完成了對(duì)觀察對(duì)象的抽象移层，因?yàn)椴恍枰~外的代碼來允許觀察值能夠被觀察.

    缺點(diǎn)：
     1.我們觀察的屬性必須使用string來定義赫粥。因此在編譯器不會(huì)出現(xiàn)警告以及檢查观话；
     2.對(duì)屬性重構(gòu)將導(dǎo)致我們的觀察代碼不再可用越平；
     3.復(fù)雜的if語句要求對(duì)象正在觀察多個(gè)值。這是因?yàn)樗械挠^察代碼通過一個(gè)方法來指向晦溪；
     4.當(dāng)釋放觀察者時(shí)不需要移除觀察者。