delegate、notification、KVO 區(qū)別

delegate、notification、KVO 區(qū)別

在開發(fā)ios應(yīng)用的時候,我們會經(jīng)常遇到一個常見的問題:在不過分耦合的前提下,controllers間怎么進行通信。在iOS應(yīng)用不斷的出現(xiàn)三種模式來實現(xiàn)這種通信:

    1.委托delegate; 特點一對一

    2.通知中心Notification Center; 特點一對多

    3.鍵值觀察key value observing,KVO 特點一對一

     三種模式都是一個對象傳遞事件給另外一個對象,并且不要他們有耦合。三種模式都是對象來通知某個事件發(fā)生了的方法,或者更準(zhǔn)確的說,是允許其他的對象收到這種事件的方法。這對于一個對象來說,是非常普通而且必須做的任務(wù),因為沒有通信,controllers將不能整合到整個應(yīng)用中。controller的另外一個目的是盡可能的自包含。我們希望controllers以自己的方式存在,在controllers層面上不能與其他的controllers進行耦合。Controllers能夠穿件其他的controllers而且他們之間可以自由通信,但是我們不希望controller又回接到創(chuàng)建自己的controller。如果我們耦合了他們,那么我們將不能復(fù)用他們,以及完全失去對應(yīng)用中一個獨立的組件的控制。

    這三種模式給controllers(也可以是其他的對象)提供通信的方法。下面將描述如何在ios應(yīng)用中使用這些模式,同樣需要注意的他們在其他的地方也會用到,并且確實是存在。
delegate
   delegate的優(yōu)勢:
  1.非常嚴格的語法。所有將聽到的事件必須是在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.weak作為屬性修飾符;
  3.在一個controller中有多個delegate對象,并且delegate是遵守同一個協(xié)議,但還是很難告訴多個對象同一個事件,不過有可能。
notification

在IOS應(yīng)用開發(fā)中有一個Notification Center的概念。它是一個單例對象,允許當(dāng)事件發(fā)生時通知一些對象。它允許我們在低程度耦合的情況下,滿足控制器與一個任意的對象進行通信的目的。這種模式的基本特征是為了讓其他的對象能夠接收到在該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與任何其他的對象進行通信,而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.我們觀察的屬性必須使用string來定義。因此在編譯器不會出現(xiàn)警告以及檢查;
     2.對屬性重構(gòu)將導(dǎo)致我們的觀察代碼不再可用;
     3.復(fù)雜的if語句要求對象正在觀察多個值。這是因為所有的觀察代碼通過一個方法來指向;
     4.當(dāng)釋放觀察者時不需要移除觀察者。
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容