iOS開發：delegate、notification、KVO的選擇

iOS開發：delegate、notification、KVO的選擇

 　　delegate、notification和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來說是匿名的，其他的使用同樣的key來註冊了該通知的對象(即觀察者)能夠對通知的事件作出反應。

　　優勢：

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

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

　　3.controller能夠傳遞context對象(dictionary)，context對象攜帶了關於發送通知的自訂的資訊

　　缺點：

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

　　2.在釋放註冊的對象時，需要在通知中樞取消註冊;

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

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

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

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

　　總結：

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

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

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

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

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