前面分別講了delegate试疙、notification和KVO的實現(xiàn)原理诵棵，以及實際使用步驟，我們心中不禁有個疑問祝旷，他們的功能比較類似履澳，那么在實際的編程中，如何選擇這些方式呢怀跛？ 在網(wǎng)上看到一個博客上詳細(xì)的分析了三者之間的區(qū)別以及各自的優(yōu)勢距贷。

在開發(fā)ios應(yīng)用的時候，我們會經(jīng)常遇到一個常見的問題：在不過分耦合的前提下吻谋，controllers間怎么進(jìn)行通信忠蝗。在IOS應(yīng)用不斷的出現(xiàn)三種模式來實現(xiàn)這種通信：
1. 委托delegation；
2. 通知中心Notification Center漓拾；
3. 鍵值觀察key value observing阁最，KVO

因此，那為什么我們需要這些模式以及什么時候用它以及什么時候不用它骇两。
下面完全根據(jù)我的開發(fā)經(jīng)驗來討論這三中模式速种。我將討論為什么我覺得某種模式要好于另外一種模式以及為什么我覺得在一定的環(huán)境下某中模式比較好。我給出的這 些原因并不是圣經(jīng)低千，而僅僅是個人觀點哟旗。如果你有什么不同的觀點或者還可以進(jìn)行補充的地方，可以聯(lián)系我栋操，一起討論闸餐。

    ***上面的三種模式是什么？***

三種模式都是一個對象傳遞事件給另外一個對象矾芙，并且不要他們有耦合舍沙。三種模式都是對象來通知某個事件發(fā)生了的方法，或者更準(zhǔn)確的說剔宪，是允許其他的對象收到 這種事件的方法拂铡。這對于一個對象來說，是非常普通而且必須做的任務(wù)葱绒，因為沒有通信感帅，controller將不能整合到整個應(yīng)用中。controller的另外一個目的是盡可能的自包含地淀。我們希望controller以自己的方式存在失球，在controller層面上不能與其他的controller 進(jìn)行耦合。controller能夠穿件其他的controller而且他們之間可以自由通信，但是我們不希望controller又回接到創(chuàng)建自己 的controller实苞。如果我們耦合了他們豺撑，那么我們將不能復(fù)用他們，以及完全失去對應(yīng)用中一個獨立的組件的控制黔牵。
這三種模式給controllers(也可以是其他的對象）提供通信的方法聪轿。下面將描述如何在ios應(yīng)用中使用這些模式，同樣需要注意的他們在其他的地方也會用到猾浦，并且確實是存在陆错。
delegation

當(dāng)我們第一次編寫ios應(yīng)用時，我們注意到不斷的在使用“delegate”金赦，并且貫穿于整個SDK音瓷。delegation模式不是IOS特有的模式，而是依賴與你過去擁有的編程背景素邪。針對它的優(yōu)勢以及為什么經(jīng)常使用到外莲，這種模式可能不是很明顯的。
delegation的基本特征是兔朦，一個controller定義了一個協(xié)議（即一系列的方法定義）偷线。該協(xié)議描述了一個delegate對象為了能 夠響應(yīng)一個controller的事件而必須做的事情。協(xié)議就是delegator說沽甥，“如果你想作為我的delegate声邦，那么你就必須實現(xiàn)這些方 法”。實現(xiàn)這些方法就是允許controller在它的delegate能夠調(diào)用這些方法摆舟，而它的delegate知道什么時候調(diào)用哪種方法亥曹。 delegate可以是任何一種對象類型，因此controller不會與某種對象進(jìn)行耦合恨诱，但是當(dāng)該對象嘗試告訴委托事情時媳瞪，該對象能確定 delegate將響應(yīng)。

delegate的優(yōu)勢：
1.非常嚴(yán)格的語法照宝。所有將聽到的事件必須是在delegate協(xié)議中有清晰的定義蛇受。
2.如果delegate中的一個方法沒有實現(xiàn)那么就會出現(xiàn)編譯警告/錯誤
3.協(xié)議必須在controller的作用域范圍內(nèi)定義
4.在一個應(yīng)用中的控制流程是可跟蹤的并且是可識別的；
5.在一個控制器中可以定義定義多個不同的協(xié)議厕鹃，每個協(xié)議有不同的delegates
6.沒有第三方對象要求保持/監(jiān)視通信過程兢仰。
7.能夠接收調(diào)用的協(xié)議方法的返回值。這意味著delegate能夠提供反饋信息給controller
** 缺點：**
1.需要定義很多代碼：1.協(xié)議定義剂碴；2.controller的delegate屬性把将；3.在delegate本身中實現(xiàn)delegate方法定義
2.在釋放代理對象時，需要小心的將delegate改為nil忆矛。一旦設(shè)定失敗察蹲，那么調(diào)用釋放對象的方法將會出現(xiàn)內(nèi)存crash
3.在一個controller中有多個delegate對象，并且delegate是遵守同一個協(xié)議，但還是很難告訴多個對象同一個事件递览，不過有可能叼屠。
notification

在IOS應(yīng)用開發(fā)中有一個”Notification Center“的概念瞳腌。它是一個單例對象绞铃，允許當(dāng)事件發(fā)生時通知一些對象。它允許我們在低程度耦合的情況下嫂侍，滿足控制器與一個任意的對象進(jìn)行通信的目的儿捧。 這種模式的基本特征是為了讓其他的對象能夠接收到在該controller中發(fā)生某種事件而產(chǎn)生的消息，controller用一個key（通知名稱）挑宠。 這樣對于controller來說是匿名的菲盾，其他的使用同樣的key來注冊了該通知的對象（即觀察者）能夠?qū)νㄖ氖录鞒龇磻?yīng)。
** 優(yōu)勢：**
1.不需要編寫多少代碼各淀，實現(xiàn)比較簡單懒鉴；
2.對于一個發(fā)出的通知，多個對象能夠做出反應(yīng)碎浇，即1對多的方式實現(xiàn)簡單
3.controller能夠傳遞context對象（dictionary）临谱，context對象攜帶了關(guān)于發(fā)送通知的自定義的信息
** 缺點：**
1.在編譯期不會檢查通知是否能夠被觀察者正確的處理；
2.在釋放注冊的對象時奴璃，需要在通知中心取消注冊悉默；
3.在調(diào)試的時候應(yīng)用的工作以及控制過程難跟蹤；
4.需要第三方對喜愛那個來管理controller與觀察者對象之間的聯(lián)系苟穆；
5.controller和觀察者需要提前知道通知名稱抄课、UserInfo dictionary keys。如果這些沒有在工作區(qū)間定義雳旅，那么會出現(xiàn)不同步的情況跟磨；
6.通知發(fā)出后，controller不能從觀察者獲得任何的反饋信息攒盈。

KVO

KVO是一個對象能夠觀察另外一個對象的屬性的值抵拘，并且能夠發(fā)現(xiàn)值的變化。前面兩種模式更加適合一個controller與任何其他的對象進(jìn)行通 信沦童，而KVO更加適合任何類型的對象偵聽另外一個任意對象的改變（這里也可以是controller仑濒，但一般不是controller）。這是一個對象與 另外一個對象保持同步的一種方法偷遗，即當(dāng)另外一種對象的狀態(tài)發(fā)生改變時墩瞳，觀察對象馬上作出反應(yīng)。它只能用來對屬性作出反應(yīng)氏豌，而不會用來對方法或者動作作出反應(yīng)喉酌。
優(yōu)點：
1.能夠提供一種簡單的方法實現(xiàn)兩個對象間的同步。例如：model和view之間同步；
2.能夠?qū)Ψ俏覀儎?chuàng)建的對象泪电，即內(nèi)部對象的狀態(tài)改變作出響應(yīng)般妙，而且不需要改變內(nèi)部對象（SKD對象）的實現(xiàn)；
3.能夠提供觀察的屬性的最新值以及先前值相速；
4.用key paths來觀察屬性碟渺，因此也可以觀察嵌套對象；
5.完成了對觀察對象的抽象突诬，因為不需要額外的代碼來允許觀察值能夠被觀察
** 缺點：**
1.我們觀察的屬性必須使用strings來定義苫拍。因此在編譯器不會出現(xiàn)警告以及檢查；
2.對屬性重構(gòu)將導(dǎo)致我們的觀察代碼不再可用旺隙；
3.復(fù)雜的“IF”語句要求對象正在觀察多個值绒极。這是因為所有的觀察代碼通過一個方法來指向；
4.當(dāng)釋放觀察者時不需要移除觀察者蔬捷。

總結(jié)：

從上面的分析中可以看出3中設(shè)計模式都有各自的優(yōu)點和缺點垄提。其實任何一種事物都是這樣，問題是如何在正確的時間正確的環(huán)境下選擇正確的事物周拐。下面就講講如何發(fā)揮他們各自的優(yōu)勢铡俐，在哪種情況下使用哪種模式。注意使用任何一種模式都沒有對和錯速妖，只有更適合或者不適合高蜂。 每一種模式都給對象提供一種方法來通知一個事件給其他對象，而且前者不需要知道偵聽者罕容。在這三種模式中备恤，我認(rèn)為KVO有最清晰的使用案例，而且針對某個需 求有清晰的實用性锦秒。而另外兩種模式有比較相似的用處露泊，并且經(jīng)常用來給controller間進(jìn)行通信。那么我們在什么情況使用其中之一呢旅择？

根據(jù)我開發(fā)iOS應(yīng)用的經(jīng)歷惭笑，我發(fā)現(xiàn)有些過分的使用通知模式。我個人不是很喜歡使用通知中心生真。我發(fā)現(xiàn)用通知中心很難把握應(yīng)用的執(zhí)行流程沉噩。 UserInfo dictionaries的keys到處傳遞導(dǎo)致失去了同步，而且在公共空間需要定義太多的常量柱蟀。對于一個工作于現(xiàn)有的項目的開發(fā)者來說川蒙，如果過分的使用 通知中心，那么很難理解應(yīng)用的流程长已。
我覺得使用命名規(guī)則好的協(xié)議和協(xié)議方法定義對于清晰的理解controllers間的通信是很容易的畜眨。努力的定義這些協(xié)議方法將增強代碼的可讀性昼牛， 以及更好的跟蹤你的app。代理協(xié)議發(fā)生改變以及實現(xiàn)都可通過編譯器檢查出來康聂，如果沒有將會在開發(fā)的過程中至少會出現(xiàn)crash贰健，而不僅僅是讓一些事情異 常工作。甚至在同一事件通知多控制器的場景中恬汁，只要你的應(yīng)用在controller層次有著良好的結(jié)構(gòu)伶椿，消息將在該層次上傳遞。該層次能夠向后傳遞直至讓 所有需要知道事件的controllers都知道蕊连。
當(dāng)然會有delegation模式不適合的例外情況出現(xiàn)悬垃，而且notification可能更加有效游昼。例如：應(yīng)用中所有的controller需要知道一個事件甘苍。然而這些類型的場景很少出現(xiàn)。另外一個例子是當(dāng)你建立了一個架構(gòu)而且需要通知該事件給正在運行中應(yīng)用烘豌。
根據(jù)經(jīng)驗载庭，如果是屬性層的時間，不管是在不需要編程的對象還是在緊緊綁定一個view對象的model對象廊佩，我只使用觀察囚聚。對于其他的事件，我都會 使用delegate模式标锄。如果因為某種原因我不能使用delegate顽铸，首先我將估計我的app架構(gòu)是否出現(xiàn)了嚴(yán)重的錯誤。如果沒有錯誤料皇，然后才使用 notification谓松。