IOS 如何選擇delegate、notification硫朦、KVO贷腕?-【轉(zhuǎn)】

原文地址:http://blog.csdn.net/dqjyong/article/details/7685933

前面分別講了delegate、notification和KVO的實(shí)現(xiàn)原理咬展,以及實(shí)際使用步驟泽裳,我們心中不禁有個(gè)疑問(wèn),他們的功能比較類(lèi)似破婆,那么在實(shí)際的編程中涮总,如何選擇這些方式呢?

在網(wǎng)上看到一個(gè)博客上詳細(xì)的分析了三者之間的區(qū)別以及各自的優(yōu)勢(shì)祷舀,博文地址為http://blog.shinetech.com/2011/06/14/delegation-notification-and-observation/瀑梗,因?yàn)椴┪氖怯糜⑽膶?xiě)的,下面將其翻譯成中文裳扯。

在開(kāi)發(fā)ios應(yīng)用的時(shí)候抛丽,我們會(huì)經(jīng)常遇到一個(gè)常見(jiàn)的問(wèn)題:在不過(guò)分耦合的前提下,controllers間怎么進(jìn)行通信饰豺。在IOS應(yīng)用不斷的出現(xiàn)三種模式來(lái)實(shí)現(xiàn)這種通信:

1.委托delegation铺纽;

2.通知中心Notification Center;

3.鍵值觀察key value observing哟忍,KVO

因此狡门,那為什么我們需要這些模式以及什么時(shí)候用它以及什么時(shí)候不用它。

下面完全根據(jù)我的開(kāi)發(fā)經(jīng)驗(yàn)來(lái)討論這三中模式锅很。我將討論為什么我覺(jué)得某種模式要好于另外一種模式以及為什么我覺(jué)得在一定的環(huán)境下某中模式比較好其馏。我給出的這些原因并不是圣經(jīng),而僅僅是個(gè)人觀點(diǎn)爆安。如果你有什么不同的觀點(diǎn)或者還可以進(jìn)行補(bǔ)充的地方叛复,可以聯(lián)系我,一起討論。

上面的三種模式是什么褐奥?

三種模式都是一個(gè)對(duì)象傳遞事件給另外一個(gè)對(duì)象咖耘,并且不要他們有耦合。三種模式都是對(duì)象來(lái)通知某個(gè)事件發(fā)生了的方法撬码,或者更準(zhǔn)確的說(shuō)儿倒,是允許其他的對(duì)象收到這種事件的方法。這對(duì)于一個(gè)對(duì)象來(lái)說(shuō)呜笑,是非常普通而且必須做的任務(wù)夫否,因?yàn)闆](méi)有通信,controllers將不能整合到整個(gè)應(yīng)用中叫胁。controller的另外一個(gè)目的是盡可能的自包含凰慈。我們希望controllers以自己的方式存在,在controllers層面上不能與其他的controllers進(jìn)行耦合驼鹅。Controllers能夠穿件其他的controllers而且他們之間可以自由通信微谓,但是我們不希望controller又回接到創(chuàng)建自己的controller。如果我們耦合了他們输钩,那么我們將不能復(fù)用他們堰酿,以及完全失去對(duì)應(yīng)用中一個(gè)獨(dú)立的組件的控制。

這三種模式給controllers(也可以是其他的對(duì)象)提供通信的方法张足。下面將描述如何在ios應(yīng)用中使用這些模式,同樣需要注意的他們?cè)谄渌牡胤揭矔?huì)用到坎藐,并且確實(shí)是存在为牍。

一、delegation

當(dāng)我們第一次編寫(xiě)ios應(yīng)用時(shí)岩馍,我們注意到不斷的在使用“delegate”碉咆,并且貫穿于整個(gè)SDK。delegation模式不是IOS特有的模式蛀恩,而是依賴(lài)與你過(guò)去擁有的編程背景疫铜。針對(duì)它的優(yōu)勢(shì)以及為什么經(jīng)常使用到,這種模式可能不是很明顯的双谆。

delegation的基本特征是壳咕,一個(gè)controller定義了一個(gè)協(xié)議(即一系列的方法定義)。該協(xié)議描述了一個(gè)delegate對(duì)象為了能夠響應(yīng)一個(gè)controller的事件而必須做的事情顽馋。協(xié)議就是delegator說(shuō)谓厘,“如果你想作為我的delegate,那么你就必須實(shí)現(xiàn)這些方法”寸谜。實(shí)現(xiàn)這些方法就是允許controller在它的delegate能夠調(diào)用這些方法竟稳,而它的delegate知道什么時(shí)候調(diào)用哪種方法。delegate可以是任何一種對(duì)象類(lèi)型,因此controller不會(huì)與某種對(duì)象進(jìn)行耦合他爸,但是當(dāng)該對(duì)象嘗試告訴委托事情時(shí)聂宾,該對(duì)象能確定delegate將響應(yīng)。

delegate的優(yōu)勢(shì):

1.非常嚴(yán)格的語(yǔ)法诊笤。所有將聽(tīng)到的事件必須是在delegate協(xié)議中有清晰的定義系谐。

2.如果delegate中的一個(gè)方法沒(méi)有實(shí)現(xiàn)那么就會(huì)出現(xiàn)編譯警告/錯(cuò)誤

3.協(xié)議必須在controller的作用域范圍內(nèi)定義

4.在一個(gè)應(yīng)用中的控制流程是可跟蹤的并且是可識(shí)別的;

5.在一個(gè)控制器中可以定義定義多個(gè)不同的協(xié)議盏混,每個(gè)協(xié)議有不同的delegates

6.沒(méi)有第三方對(duì)象要求保持/監(jiān)視通信過(guò)程蔚鸥。

7.能夠接收調(diào)用的協(xié)議方法的返回值。這意味著delegate能夠提供反饋信息給controller

缺點(diǎn):

1.需要定義很多代碼:1.協(xié)議定義许赃;2.controller的delegate屬性止喷;3.在delegate本身中實(shí)現(xiàn)delegate方法定義

2.在釋放代理對(duì)象時(shí),需要小心的將delegate改為nil混聊。一旦設(shè)定失敗弹谁,那么調(diào)用釋放對(duì)象的方法將會(huì)出現(xiàn)內(nèi)存crash

3.在一個(gè)controller中有多個(gè)delegate對(duì)象,并且delegate是遵守同一個(gè)協(xié)議句喜,但還是很難告訴多個(gè)對(duì)象同一個(gè)事件预愤,不過(guò)有可能。

二咳胃、notification

在IOS應(yīng)用開(kāi)發(fā)中有一個(gè)”Notification Center“的概念植康。它是一個(gè)單例對(duì)象,允許當(dāng)事件發(fā)生時(shí)通知一些對(duì)象展懈。它允許我們?cè)诘统潭锐詈系那闆r下销睁,滿(mǎn)足控制器與一個(gè)任意的對(duì)象進(jìn)行通信的目的。這種模式的基本特征是為了讓其他的對(duì)象能夠接收到在該controller中發(fā)生某種事件而產(chǎn)生的消息存崖,controller用一個(gè)key(通知名稱(chēng))冻记。這樣對(duì)于controller來(lái)說(shuō)是匿名的,其他的使用同樣的key來(lái)注冊(cè)了該通知的對(duì)象(即觀察者)能夠?qū)νㄖ氖录鞒龇磻?yīng)来惧。

優(yōu)勢(shì):

1.不需要編寫(xiě)多少代碼冗栗,實(shí)現(xiàn)比較簡(jiǎn)單;

2.對(duì)于一個(gè)發(fā)出的通知供搀,多個(gè)對(duì)象能夠做出反應(yīng)隅居,即1對(duì)多的方式實(shí)現(xiàn)簡(jiǎn)單

3.controller能夠傳遞context對(duì)象(dictionary),context對(duì)象攜帶了關(guān)于發(fā)送通知的自定義的信息

缺點(diǎn):

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

2.在釋放注冊(cè)的對(duì)象時(shí)军浆,需要在通知中心取消注冊(cè);

3.在調(diào)試的時(shí)候應(yīng)用的工作以及控制過(guò)程難跟蹤挡闰;

4.需要第三方對(duì)喜愛(ài)那個(gè)來(lái)管理controller與觀察者對(duì)象之間的聯(lián)系乒融;

5.controller和觀察者需要提前知道通知名稱(chēng)掰盘、UserInfo dictionary keys。如果這些沒(méi)有在工作區(qū)間定義赞季,那么會(huì)出現(xiàn)不同步的情況愧捕;

6.通知發(fā)出后,controller不能從觀察者獲得任何的反饋信息申钩。

三次绘、KVO

KVO是一個(gè)對(duì)象能夠觀察另外一個(gè)對(duì)象的屬性的值,并且能夠發(fā)現(xiàn)值的變化撒遣。前面兩種模式更加適合一個(gè)controller與任何其他的對(duì)象進(jìn)行通信邮偎,而KVO更加適合任何類(lèi)型的對(duì)象偵聽(tīng)另外一個(gè)任意對(duì)象的改變(這里也可以是controller,但一般不是controller)义黎。這是一個(gè)對(duì)象與另外一個(gè)對(duì)象保持同步的一種方法禾进,即當(dāng)另外一種對(duì)象的狀態(tài)發(fā)生改變時(shí),觀察對(duì)象馬上作出反應(yīng)廉涕。它只能用來(lái)對(duì)屬性作出反應(yīng)泻云,而不會(huì)用來(lái)對(duì)方法或者動(dòng)作作出反應(yīng)

優(yōu)點(diǎn):

1.能夠提供一種簡(jiǎn)單的方法實(shí)現(xiàn)兩個(gè)對(duì)象間的同步狐蜕。例如:model和view之間同步宠纯;

2.能夠?qū)Ψ俏覀儎?chuàng)建的對(duì)象,即內(nèi)部對(duì)象的狀態(tài)改變作出響應(yīng)层释,而且不需要改變內(nèi)部對(duì)象(SKD對(duì)象)的實(shí)現(xiàn)婆瓜;

3.能夠提供觀察的屬性的最新值以及先前值;

4.用key paths來(lái)觀察屬性贡羔,因此也可以觀察嵌套對(duì)象廉白;

5.完成了對(duì)觀察對(duì)象的抽象,因?yàn)椴恍枰~外的代碼來(lái)允許觀察值能夠被觀察

缺點(diǎn):

1.我們觀察的屬性必須使用strings來(lái)定義治力。因此在編譯器不會(huì)出現(xiàn)警告以及檢查;

2.對(duì)屬性重構(gòu)將導(dǎo)致我們的觀察代碼不再可用勃黍;

3.復(fù)雜的“IF”語(yǔ)句要求對(duì)象正在觀察多個(gè)值宵统。這是因?yàn)樗械挠^察代碼通過(guò)一個(gè)方法來(lái)指向;

4.當(dāng)釋放觀察者時(shí)不需要移除觀察者覆获。

四马澈、總結(jié):

從上面的分析中可以看出3中設(shè)計(jì)模式都有各自的優(yōu)點(diǎn)和缺點(diǎn)。其實(shí)任何一種事物都是這樣弄息,問(wèn)題是如何在正確的時(shí)間正確的環(huán)境下選擇正確的事物痊班。下面就講講如何發(fā)揮他們各自的優(yōu)勢(shì),在哪種情況下使用哪種模式摹量。注意使用任何一種模式都沒(méi)有對(duì)和錯(cuò)涤伐,只有更適合或者不適合馒胆。每一種模式都給對(duì)象提供一種方法來(lái)通知一個(gè)事件給其他對(duì)象,而且前者不需要知道偵聽(tīng)者凝果。在這三種模式中祝迂,我認(rèn)為KVO有最清晰的使用案例,而且針對(duì)某個(gè)需求有清晰的實(shí)用性器净。而另外兩種模式有比較相似的用處型雳,并且經(jīng)常用來(lái)給controller間進(jìn)行通信。那么我們?cè)谑裁辞闆r使用其中之一呢山害?

根據(jù)我開(kāi)發(fā)iOS應(yīng)用的經(jīng)歷纠俭,我發(fā)現(xiàn)有些過(guò)分的使用通知模式。我個(gè)人不是很喜歡使用通知中心浪慌。我發(fā)現(xiàn)用通知中心很難把握應(yīng)用的執(zhí)行流程冤荆。UserInfo dictionaries的keys到處傳遞導(dǎo)致失去了同步,而且在公共空間需要定義太多的常量眷射。對(duì)于一個(gè)工作于現(xiàn)有的項(xiàng)目的開(kāi)發(fā)者來(lái)說(shuō)匙赞,如果過(guò)分的使用通知中心,那么很難理解應(yīng)用的流程妖碉。

我覺(jué)得使用命名規(guī)則好的協(xié)議和協(xié)議方法定義對(duì)于清晰的理解controllers間的通信是很容易的涌庭。努力的定義這些協(xié)議方法將增強(qiáng)代碼的可讀性,以及更好的跟蹤你的app欧宜。代理協(xié)議發(fā)生改變以及實(shí)現(xiàn)都可通過(guò)編譯器檢查出來(lái)坐榆,如果沒(méi)有將會(huì)在開(kāi)發(fā)的過(guò)程中至少會(huì)出現(xiàn)crash,而不僅僅是讓一些事情異常工作冗茸。甚至在同一事件通知多控制器的場(chǎng)景中席镀,只要你的應(yīng)用在controller層次有著良好的結(jié)構(gòu),消息將在該層次上傳遞夏漱。該層次能夠向后傳遞直至讓所有需要知道事件的controllers都知道豪诲。

當(dāng)然會(huì)有delegation模式不適合的例外情況出現(xiàn),而且notification可能更加有效挂绰。例如:應(yīng)用中所有的controller需要知道一個(gè)事件屎篱。然而這些類(lèi)型的場(chǎng)景很少出現(xiàn)。另外一個(gè)例子是當(dāng)你建立了一個(gè)架構(gòu)而且需要通知該事件給正在運(yùn)行中應(yīng)用葵蒂。

根據(jù)經(jīng)驗(yàn)交播,如果是屬性層的時(shí)間,不管是在不需要編程的對(duì)象還是在緊緊綁定一個(gè)view對(duì)象的model對(duì)象践付,我只使用觀察秦士。對(duì)于其他的事件,我都會(huì)使用delegate模式永高。如果因?yàn)槟撤N原因我不能使用delegate隧土,首先我將估計(jì)我的app架構(gòu)是否出現(xiàn)了嚴(yán)重的錯(cuò)誤提针。如果沒(méi)有錯(cuò)誤,然后才使用notification次洼。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末关贵,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子卖毁,更是在濱河造成了極大的恐慌揖曾,老刑警劉巖,帶你破解...
    沈念sama閱讀 222,681評(píng)論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件亥啦,死亡現(xiàn)場(chǎng)離奇詭異炭剪,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī)翔脱,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,205評(píng)論 3 399
  • 文/潘曉璐 我一進(jìn)店門(mén)奴拦,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人届吁,你說(shuō)我怎么就攤上這事错妖。” “怎么了疚沐?”我有些...
    開(kāi)封第一講書(shū)人閱讀 169,421評(píng)論 0 362
  • 文/不壞的土叔 我叫張陵暂氯,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我亮蛔,道長(zhǎng)痴施,這世上最難降的妖魔是什么? 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 60,114評(píng)論 1 300
  • 正文 為了忘掉前任究流,我火速辦了婚禮辣吃,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘芬探。我一直安慰自己神得,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 69,116評(píng)論 6 398
  • 文/花漫 我一把揭開(kāi)白布偷仿。 她就那樣靜靜地躺著哩簿,像睡著了一般。 火紅的嫁衣襯著肌膚如雪炎疆。 梳的紋絲不亂的頭發(fā)上卡骂,一...
    開(kāi)封第一講書(shū)人閱讀 52,713評(píng)論 1 312
  • 那天国裳,我揣著相機(jī)與錄音形入,去河邊找鬼。 笑死缝左,一個(gè)胖子當(dāng)著我的面吹牛亿遂,可吹牛的內(nèi)容都是我干的浓若。 我是一名探鬼主播,決...
    沈念sama閱讀 41,170評(píng)論 3 422
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼蛇数,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼挪钓!你這毒婦竟也來(lái)了?” 一聲冷哼從身側(cè)響起耳舅,我...
    開(kāi)封第一講書(shū)人閱讀 40,116評(píng)論 0 277
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤碌上,失蹤者是張志新(化名)和其女友劉穎,沒(méi)想到半個(gè)月后浦徊,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體馏予,經(jīng)...
    沈念sama閱讀 46,651評(píng)論 1 320
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,714評(píng)論 3 342
  • 正文 我和宋清朗相戀三年盔性,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了霞丧。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 40,865評(píng)論 1 353
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡冕香,死狀恐怖蛹尝,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情悉尾,我是刑警寧澤突那,帶...
    沈念sama閱讀 36,527評(píng)論 5 351
  • 正文 年R本政府宣布,位于F島的核電站焕襟,受9級(jí)特大地震影響陨收,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜鸵赖,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,211評(píng)論 3 336
  • 文/蒙蒙 一务漩、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧它褪,春花似錦饵骨、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 32,699評(píng)論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至老赤,卻和暖如春轮洋,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背抬旺。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 33,814評(píng)論 1 274
  • 我被黑心中介騙來(lái)泰國(guó)打工弊予, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人开财。 一個(gè)月前我還...
    沈念sama閱讀 49,299評(píng)論 3 379
  • 正文 我出身青樓汉柒,卻偏偏與公主長(zhǎng)得像误褪,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子碾褂,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,870評(píng)論 2 361

推薦閱讀更多精彩內(nèi)容