delegate notification kvo三者比較

IOS 如何選擇delegate、notification、KVO？

  前面分別講了delegate、notification和KVO的實現原理，以及實際使用步驟，咱們心中不由有個疑問，他們的功能比較相似，那麼在實際的編程中，如何選擇這些方式呢？

 

 

 

  在網上看到一個博客上詳細的分析了三者之間的區別以及各自的優點，博文地址爲http://blog.shinetech.com/2011/06/14/delegation-notification-and-observation/，由於博文是用英文寫的，下面將其翻譯成中文。

 

 

 

  在開發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。