delegate、notification和KVO的功能比較類似，那么在實(shí)際的編程中，如何選擇這些方式呢？

       在網(wǎng)上看到一個(gè)博客上詳細(xì)的分析了三者之間的區(qū)別以及各自的優(yōu)勢(shì)，博文地址為http://blog.shinetech.com/2011/06/14/delegation-notification-and-observation/，因?yàn)椴┪氖怯糜⑽膶懙?，下面將其翻譯成中文。

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

        1.委托delegation；

        2.通知中心Notification Center；

        3.鍵值觀察key value observing，KVO

        因此，那為什么我們需要這些模式以及什么時(shí)候用它以及什么時(shí)候不用它。

        下面完全根據(jù)我的開發(fā)經(jīng)驗(yàn)來(lái)討論這三中模式。我將討論為什么我覺(jué)得某種模式要好于另外一種模式以及為什么我覺(jué)得在一定的環(huán)境下某中模式比較好。我給出的這 些原因并不是圣經(jīng)，而僅僅是個(gè)人觀點(diǎn)。如果你有什么不同的觀點(diǎn)或者還可以進(jìn)行補(bǔ)充的地方，可以聯(lián)系我，一起討論。

        上面的三種模式是什么？

         三種模式都是一個(gè)對(duì)象傳遞事件給另外一個(gè)對(duì)象，并且不要他們有耦合。三種模式都是對(duì)象來(lái)通知某個(gè)事件發(fā)生了的方法，或者更準(zhǔn)確的說(shuō)，是允許其他的對(duì)象收到 這種事件的方法。這對(duì)于一個(gè)對(duì)象來(lái)說(shuō)，是非常普通而且必須做的任務(wù)，因?yàn)闆](méi)有通信，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í)是存在。

• delegation

當(dāng)我們第一次編寫ios應(yīng)用時(shí)，我們注意到不斷的在使用“delegate”，并且貫穿于整個(gè)SDK。delegation模式不是IOS特有的模式，而是依賴與你過(guò)去擁有的編程背景。針對(duì)它的優(yōu)勢(shì)以及為什么經(jīng)常使用到，這種模式可能不是很明顯的。

delegation的基本特征是，一個(gè)controller定義了一個(gè)協(xié)議（即一系列的方法定義）。該協(xié)議描述了一個(gè)delegate對(duì)象為了能夠響應(yīng) 一個(gè)controller的事件而必須做的事情。協(xié)議就是delegator說(shuō)，“如果你想作為我的delegate，那么你就必須實(shí)現(xiàn)這些方法”。實(shí)現(xiàn) 這些方法就是允許controller在它的delegate能夠調(diào)用這些方法，而它的delegate知道什么時(shí)候調(diào)用哪種方法。delegate可以 是任何一種對(duì)象類型，因此controller不會(huì)與某種對(duì)象進(jìn)行耦合，但是當(dāng)該對(duì)象嘗試告訴委托事情時(shí)，該對(duì)象能確定delegate將響應(yīng)。

       delegate的優(yōu)勢(shì)：

      1.非常嚴(yán)格的語(yǔ)法。所有將聽到的事件必須是在delegate協(xié)議中有清晰的定義。

      2.如果delegate中的一個(gè)方法沒(méi)有實(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.沒(méi)有第三方對(duì)象要求保持/監(jiān)視通信過(guò)程。

      7.能夠接收調(diào)用的協(xié)議方法的返回值。這意味著delegate能夠提供反饋信息給controller

      缺點(diǎn)：

      1.需要定義很多代碼：1.協(xié)議定義；2.controller的delegate屬性；3.在delegate本身中實(shí)現(xiàn)delegate方法定義

      2.在釋放代理對(duì)象時(shí)，需要小心的將delegate改為nil。一旦設(shè)定失敗，那么調(diào)用釋放對(duì)象的方法將會(huì)出現(xiàn)內(nèi)存crash

      3.在一個(gè)controller中有多個(gè)delegate對(duì)象，并且delegate是遵守同一個(gè)協(xié)議，但還是很難告訴多個(gè)對(duì)象同一個(gè)事件，不過(guò)有可能。

• 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來(lái)說(shuō)是匿名的，其他的使用同樣的key來(lái)注冊(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)用的工作以及控制過(guò)程難跟蹤；

        4.需要第三方對(duì)喜愛那個(gè)來(lái)管理controller與觀察者對(duì)象之間的聯(lián)系；

        5.controller和觀察者需要提前知道通知名稱、UserInfo dictionary keys。如果這些沒(méi)有在工作區(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)。它只能用來(lái)對(duì)屬性作出反應(yīng)，而不會(huì)用來(lái)對(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來(lái)觀察屬性，因此也可以觀察嵌套對(duì)象；

         5.完成了對(duì)觀察對(duì)象的抽象，因?yàn)椴恍枰~外的代碼來(lái)允許觀察值能夠被觀察

        缺點(diǎn)：

         1.我們觀察的屬性必須使用strings來(lái)定義。因此在編譯器不會(huì)出現(xiàn)警告以及檢查；

         2.對(duì)屬性重構(gòu)將導(dǎo)致我們的觀察代碼不再可用；

         3.復(fù)雜的“IF”語(yǔ)句要求對(duì)象正在觀察多個(gè)值。這是因?yàn)樗械挠^察代碼通過(guò)一個(gè)方法來(lái)指向；

         4.當(dāng)釋放觀察者時(shí)不需要移除觀察者。

總結(jié)：

從上面的分析中可以看出3種設(shè)計(jì)模式都有各自的優(yōu)點(diǎn)和缺點(diǎn)。其實(shí)任何一種事物都是這樣，問(wèn)題是如何在正確的時(shí)間正確的環(huán)境下選擇正確的事物。下面就講講如何發(fā)揮他們各自的優(yōu)勢(shì)，在哪種情況下使用哪種模式。注意使用任何一種模式都沒(méi)有對(duì)和錯(cuò)，只有更適合或者不適合。 每一種模式都給對(duì)象提供一種方法來(lái)通知一個(gè)事件給其他對(duì)象，而且前者不需要知道偵聽者。在這三種模式中，我認(rèn)為KVO有最清晰的使用案例，而且針對(duì)某個(gè)需 求有清晰的實(shí)用性。而另外兩種模式有比較相似的用處，并且經(jīng)常用來(lái)給controller間進(jìn)行通信。那么我們?cè)谑裁辞闆r使用其中之一呢？

根據(jù)我開發(fā)iOS應(yīng)用的經(jīng)歷，我發(fā)現(xiàn)有些過(guò)分的使用通知模式。我個(gè)人不是很喜歡使用通知中心。我發(fā)現(xiàn)用通知中心很難把握應(yīng)用的執(zhí)行流程。UserInfo dictionaries的keys到處傳遞導(dǎo)致失去了同步，而且在公共空間需要定義太多的常量。對(duì)于一個(gè)工作于現(xiàn)有的項(xiàng)目的開發(fā)者來(lái)說(shuō)，如果過(guò)分的使用 通知中心，那么很難理解應(yīng)用的流程。

我覺(jué)得使用命名規(guī)則好的協(xié)議和協(xié)議方法定義對(duì)于清晰的理解controllers間的通信是很容易的。努力的定義這些協(xié)議方法將增強(qiáng)代碼的可讀性，以及更 好的跟蹤你的app。代理協(xié)議發(fā)生改變以及實(shí)現(xiàn)都可通過(guò)編譯器檢查出來(lái)，如果沒(méi)有將會(huì)在開發(fā)的過(guò)程中至少會(huì)出現(xiàn)crash，而不僅僅是讓一些事情異常工 作。甚至在同一事件通知多控制器的場(chǎng)景中，只要你的應(yīng)用在controller層次有著良好的結(jié)構(gòu)，消息將在該層次上傳遞。該層次能夠向后傳遞直至讓所有 需要知道事件的controllers都知道。

當(dāng)然會(huì)有delegation模式不適合的例外情況出現(xiàn)，而且notification可能更加有效。例如：應(yīng)用中所有的controller需要知道一個(gè)事件。然而這些類型的場(chǎng)景很少出現(xiàn)。另外一個(gè)例子是當(dāng)你建立了一個(gè)架構(gòu)而且需要通知該事件給正在運(yùn)行中應(yīng)用。

根據(jù)經(jīng)驗(yàn)，如果是屬性層的時(shí)間，不管是在不需要編程的對(duì)象還是在緊緊綁定一個(gè)view對(duì)象的model對(duì)象，我只使用觀察。對(duì)于其他的事件，我都會(huì)使用 delegate模式。如果因?yàn)槟撤N原因我不能使用delegate，首先我將估計(jì)我的app架構(gòu)是否出現(xiàn)了嚴(yán)重的錯(cuò)誤。如果沒(méi)有錯(cuò)誤，然后才使用 notification。