delegate,notifucation,KVO三種模式實作通信的優缺點

         在開發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來說是匿名的，Source Code其他的使用同樣的key來注冊了該通知的對象（即觀察者）能夠對通知的事件作出反應。

        優勢：

        1.不需要編寫多少代碼，實作比較簡單；

        2.對于一個發出的通知，多個對象能夠做出反應，即1對多的方式實作簡單

        3.controller能夠傳遞context對象（dictionary），context對象攜帶了關于發送通知的自定義的資訊

        缺點：

        1.在編譯期不會檢查通知是否能夠被觀察者正确的處理；

        2.在釋放注冊的對象時，需要在通知中心取消注冊；

        3.在調試的時候應用的工作以及控制過程難跟蹤；

        4.需要第三方對喜愛那個來管理controller與觀察者對象之間的聯系；

        5.controller和觀察者需要提前知道通知名稱http://www.androide-apps.com/、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”語句要求對象正在觀察多個值http://www.pudncom.com/ 。這是因為所有的觀察代碼通過一個方法來指向；

         4.當釋放觀察者時不需要移除觀察者。

總結：

從上面的分析中可以看出3中設計模式都有各自的優點和缺點。其實任何一種事物都是這樣，問題是如何在正确的時間正确的環境下選擇正确的事物。下面就講講如何發揮他們各自的優勢，在哪種情況下使用哪種模式。注意使用任何一種模式都沒有對和錯，隻有更适合或者不适合。每一種模式都給對象提供一種方法來通知一個事件給其他對象，而且前者不需要知道偵聽者。在這三種模式中，我認為KVO有最清晰的使用案例，而且針對某個需求有清晰的實用性。而另外兩種模式有比較相似的用處，并且經常用來給controller間進行通信。那麼我們在什麼情況使用其中之一呢？

根據我開發iOS應用的經曆，我發現有些過分的使用通知模式。我個人不是很喜歡使用通知中心。我發現用通知中心很難把握應用的執行流程。UserInfo dictionaries的keys到處傳遞導緻失去了同步，而且在公共空間需要定義太多的常量。對于一個工作于現有的項目的開發者來說，如果過分的使用通知中心，那麼很難了解應用的流程。

我覺得使用命名規則好的協定和協定方法定義對于清晰的了解controllers間的通信是很容易的。努力的定義這些協定方法将增強代碼的可讀性，以及更好的跟蹤你的app。代理協定發生改變以及實作都可通過編譯器檢查出來，如果沒有将會在開發的過程中至少會出現crash，而不僅僅是讓一些事情異常工作。甚至在同一事件通知多控制器的場景中，隻要你的應用在controller層次有着良好的結構，消息将在該層次上傳遞。該層次能夠向後傳遞直至讓所有需要知道事件的controllers都知道。

當然會有delegation模式不适合的例外情況出現，而且notification可能更加有效。例如：應用中所有的controller需要知道一個事件。然而這些類型的場景很少出現。另外一個例子是當你建立了一個架構而且需要通知該事件給正在運作中應用。

根據經驗，如果是屬性層的事件，不管是在不需要程式設計的對象還是在緊緊綁定一個view對象的model對象，我隻使用KVO。對于其他的事件，我都會使用delegate模式。如果因為某種原因我不能使用delegate，首先我将估計我的app架構是否出現了嚴重的錯誤。如果沒有錯誤，然後才使用notification。