在ios中controllers間是怎樣進行通信,主要是通過1.委托(代理)delegation2.通知 Notification Center 3.鍵值觀察 key value observing (kvo)
他們之間相同點
三種模式都是一個對象傳遞事件給另一個對象,不需要有耦合;
三種模式都是對象來通知某個事件發(fā)生方法,其實就是允許其他對象收到這種事件的方法.
他們之間的區(qū)別
1.delegation
delegation的基本特征,cotroller定義了一個協(xié)議,該協(xié)議描述一個delegate對象為了能夠響應該controller的事件而必須做的事.協(xié)議就是delegator說，“如果你想作為我的delegate，那么你就必須實現(xiàn)這些方法”。實現(xiàn)這些方法就是允許controller在它的delegate能夠調用這些方法，而它的delegate知道什么時候調用哪種方法。delegate可以是任何一種對象類型，因此controller不會與某種對象進行耦合，但是當該對象嘗試告訴委托事情時，該對象能確定delegate將響應。
delegate的優(yōu)勢：
1.非常嚴格的語法。所有將聽到的事件必須是在delegate協(xié)議中有清晰的定義。2.如果delegate中的一個方法沒有實現(xiàn)那么就會出現(xiàn)編譯警告/錯誤3.協(xié)議必須在controller的作用域范圍內定義4.在一個應用中的控制流程是可跟蹤的并且是可識別的；5.在一個控制器中可以定義定義多個不同的協(xié)議，每個協(xié)議有不同的delegates6.沒有第三方對象要求保持/監(jiān)視通信過程。7.能夠接收調用的協(xié)議方法的返回值。這意味著delegate能夠提供反饋信息給controller
缺點：
1.需要定義很多代碼：1.協(xié)議定義；2.controller的delegate屬性；3.在delegate本身中實現(xiàn)delegate方法定義2.在釋放代理對象時，需要小心的將delegate改為nil。一旦設定失敗，那么調用釋放對象的方法將會出現(xiàn)內存crash3.在一個controller中有多個delegate對象，并且delegate是遵守同一個協(xié)議，但還是很難告訴多個對象同一個事件，不過有可能。
二、Notification
在IOS應用開發(fā)中有一個”Notification Center“的概念。它是一個單例對象，允許當事件發(fā)生時通知一些對象。它允許我們在低程度耦合的情況下，滿足控制器與一個任意的對象進行通信的目的。這種模式的基本特征是為了讓其他的對象能夠接收到在該controller中發(fā)生某種事件而產生的消息，controller用一個key（通知名稱）。這樣對于controller來說是匿名的，其他的使用同樣的key來注冊了該通知的對象（即觀察者）能夠對通知的事件作出反應。
優(yōu)勢：
1.不需要編寫多少代碼，實現(xiàn)比較簡單；2.對于一個發(fā)出的通知，多個對象能夠做出反應，即1對多的方式實現(xiàn)簡單3.controller能夠傳遞context對象（dictionary），context對象攜帶了關于發(fā)送通知的自定義的信息
缺點：
1.在編譯期不會檢查通知是否能夠被觀察者正確的處理；2.在釋放注冊的對象時，需要在通知中心取消注冊；3.在調試的時候應用的工作以及控制過程難跟蹤；4.需要第三方對喜愛那個來管理controller與觀察者對象之間的聯(lián)系；5.controller和觀察者需要提前知道通知名稱、UserInfo dictionary keys。如果這些沒有在工作區(qū)間定義，那么會出現(xiàn)不同步的情況；6.通知發(fā)出后，controller不能從觀察者獲得任何的反饋信息。
三、KVO
KVO是一個對象能夠觀察另外一個對象的屬性的值，并且能夠發(fā)現(xiàn)值的變化。前面兩種模式更加適合一個controller與任何其他的對象進行通信，而KVO更加適合任何類型的對象偵聽另外一個任意對象的改變（這里也可以是controller，但一般不是controller）。這是一個對象與另外一個對象保持同步的一種方法，即當另外一種對象的狀態(tài)發(fā)生改變時，觀察對象馬上作出反應。它只能用來對屬性作出反應，而不會用來對方法或者動作作出反應。
優(yōu)點：
1.能夠提供一種簡單的方法實現(xiàn)兩個對象間的同步。例如：model和view之間同步；2.能夠對非我們創(chuàng)建的對象，即內部對象的狀態(tài)改變作出響應，而且不需要改變內部對象（SKD對象）的實現(xiàn)；3.能夠提供觀察的屬性的最新值以及先前值；4.用key paths來觀察屬性，因此也可以觀察嵌套對象；5.完成了對觀察對象的抽象，因為不需要額外的代碼來允許觀察值能夠被觀察
缺點：
1.我們觀察的屬性必須使用strings來定義。因此在編譯器不會出現(xiàn)警告以及檢查；2.對屬性重構將導致我們的觀察代碼不再可用；3.復雜的“IF”語句要求對象正在觀察多個值。這是因為所有的觀察代碼通過一個方法來指向；4.當釋放觀察者時不需要移除觀察者。
總結:
從上面的分析中可以看出3中設計模式都有各自的優(yōu)點和缺點。其實任何一種事物都是這樣，問題是如何在正確的時間正確的環(huán)境下選擇正確的事物。下面就講講如何發(fā)揮他們各自的優(yōu)勢，在哪種情況下使用哪種模式。注意使用任何一種模式都沒有對和錯，只有更適合或者不適合。每一種模式都給對象提供一種方法來通知一個事件給其他對象，而且前者不需要知道偵聽者。在這三種模式中，我認為KVO有最清晰的使用案例，而且針對某個需求有清晰的實用性。而另外兩種模式有比較相似的用處，并且經常用來給controller間進行通信。那么我們在什么情況使用其中之一呢？根據(jù)我開發(fā)iOS應用的經歷，我發(fā)現(xiàn)有些過分的使用通知模式。我個人不是很喜歡使用通知中心。我發(fā)現(xiàn)用通知中心很難把握應用的執(zhí)行流程。UserInfo dictionaries的keys到處傳遞導致失去了同步，而且在公共空間需要定義太多的常量。對于一個工作于現(xiàn)有的項目的開發(fā)者來說，如果過分的使用通知中心，那么很難理解應用的流程。我覺得使用命名規(guī)則好的協(xié)議和協(xié)議方法定義對于清晰的理解controllers間的通信是很容易的。努力的定義這些協(xié)議方法將增強代碼的可讀性，以及更好的跟蹤你的app。代理協(xié)議發(fā)生改變以及實現(xiàn)都可通過編譯器檢查出來，如果沒有將會在開發(fā)的過程中至少會出現(xiàn)crash，而不僅僅是讓一些事情異常工作。甚至在同一事件通知多控制器的場景中，只要你的應用在controller層次有著良好的結構，消息將在該層次上傳遞。該層次能夠向后傳遞直至讓所有需要知道事件的controllers都知道。當然會有delegation模式不適合的例外情況出現(xiàn)，而且notification可能更加有效。例如：應用中所有的controller需要知道一個事件。然而這些類型的場景很少出現(xiàn)。另外一個例子是當你建立了一個架構而且需要通知該事件給正在運行中應用。根據(jù)經驗，如果是屬性層的時間，不管是在不需要編程的對象還是在緊緊綁定一個view對象的model對象，我只使用觀察。對于其他的事件，我都會使用delegate模式。如果因為某種原因我不能使用delegate，首先我將估計我的app架構是否出現(xiàn)了嚴重的錯誤。如果沒有錯誤，然后才使用notification。
文／Se7ven（簡書作者）原文鏈接：http://www.lxweimin.com/p/21c06921f3a2著作權歸作者所有，轉載請聯(lián)系作者獲得授權，并標注“簡書作者”。