Block和Delegate的對比與選擇

原文:http://blog.stablekernel.com/blocks-or-delegates/

名詞解釋:

Block: Objective-C/Swift中對閉包(closure)的實現(xiàn),廣泛使用在回調(diào)上。
Delegate: Cocoa的基本設(shè)計模式之一,面向協(xié)議(protocol)的編程,廣泛使用在回調(diào)和對象間傳值。

譯文:

在我上一篇博客發(fā)表之后,saambarat問了我一個很好的問題,“在需要回調(diào)是,什么時候使用block,什么時候使用delegate?”。
通常在這種情況下,我會問我自己,”蘋果官方是怎么做的?”。我們當然可以知道蘋果是怎么做的,通過閱讀官方文檔,因為它本身就是一個設(shè)計模式指南。
我們需要找出蘋果官方在哪里使用了delegate,在哪里使用了block。如果我們在官方文檔的選擇中發(fā)現(xiàn)了一些規(guī)律,我們可以得出一些規(guī)律幫助我們在自己的代碼里做選擇。

下面就是我的一些發(fā)現(xiàn)

1.大多數(shù)的delegate protocol有若干個消息

以GKMatch類為例,其中包含若干種消息,如:接收到其他播放器傳來的數(shù)據(jù)時、播放器改變狀態(tài)時、發(fā)生錯誤時和當播放器需要重置時,它們是不同的消息。如果蘋果在此處使用block,那么有兩個選擇,一種方式是為每一個事件注冊一個Block。如果有人寫了類似這樣的代碼,那真的會很糟糕。
另一種方式就是創(chuàng)建一個block,接受所有的可能的輸出,類似

Swift:
var matchBlock:(eventType:GKMatchEvent,player:Player,data:NSData,err:NSError)->Void

Objective-C:
void (^matchBlock)(GKMatchEventeventType, Player *player, NSData *data, NSError *err);

這樣的寫法既不方便也不可讀,所以你不會見到這種代碼。如果你在別處遇到了這種代碼,你也會被它搞得一臉懵逼。
所以,我們可以得出,如果一個對象有兩個或以上不同的事件,使用delegation

2.一個對象只能用一個delegate

因為一個對象只能有一個delegate,并且他只能調(diào)用這一個delegate。我們考察CLLicationManager,這個location manager的類在定位成功時需要通知一個對象。當然,如果我們需要幾個對象同時更新,我們可能要創(chuàng)建一個新的location manager
如果CLLocationManager是一個單例呢?這時候我們只能有一個location manager對象,所以我們考慮交換delegate的引用,指向任何一個需要location數(shù)據(jù)的對象(或者,發(fā)送一個只有你自己才知道的廣播,給其他所有對象)。所以,在單例模式中使用delegate并不合適。
這種情況最合適的例子就是UIAccelerometer.在早期的iOS版本中,accelerometer的單例實例有一個delegate,我們需要時常改變delegate的引用。這實在是太愚蠢了,所以在之后的iOS版本中被替換了?,F(xiàn)在,所有對象可以在CMMotionManager附加一個block,并且不影響其他對象接受回調(diào)。
所以,我們可以得出,如果一個對象是單例,不應(yīng)該使用delegation

3.一些delegate期望得到返回值

如果你觀察一些delegate方法(幾乎所有的dataSource方法),它們都有一個期望的返回值。這意味著擁有delegate的對象正在請求某種狀態(tài)。Block的運行機制決定它可以維持狀態(tài)或者推斷狀態(tài),就像一個對象(實際上block在底層就是一個對象)。
請想一想,如果我請求一個block“你覺得Bob這個人怎么樣?”,它只能做兩件事:返回Bob這個對象,或者返回詢問Bob的結(jié)果。如果它返回的是Bob這個對象,我們實際上可以省略block而直接去獲取Bob對象;如果它返回的是詢問Bob的結(jié)果,這不應(yīng)該作為Bob對象的一個屬性么?
從這個角度看,我們可以得出,如果對象在回調(diào)時需要額外的信息,大多數(shù)情況下應(yīng)該使用delegation

4.過程VS結(jié)果

如果我們觀察NSURLConnectionDelegate和NSURLConnectionDataDelegate,我們看到的消息就類似”我正開始做某某事”,”我只知道這么多”,”我做完了這件事”,”上帝我就要析構(gòu)了,我要狗帶了~”。這些消息都概述了,這個方法應(yīng)該在delegate的目標對象的什么過程中被調(diào)用。
因此我們可以說,delegate回調(diào)是更面向過程化的,而block回調(diào)是面向結(jié)果的。如果你僅僅是想獲得你請求的信息(或是請求失敗的錯誤信息),你應(yīng)該使用block。(如果你結(jié)合第三點看,你會意識到delegate可以維持多種事件之間的狀態(tài),而多個單獨的block則做不到。)
我又想到了兩點。第一,如果你選擇使用blocks來發(fā)起一個可能失敗的request,你應(yīng)該只使用一個block。我見過這樣的代碼:

Swift:
fetcher.makeRequest({
    result:AnyObject in
    /*do something with result*/
},error:{
    err:NSError? in
    /*do something with error*/
})

Objective-C:
[fetcher makeRequest:^(id result) {
    /*do something with result*/
} error:^(NSError *err) {
    /*do something with error*/
}];

上面的代碼則比下面的代碼更不可讀

Swift:
fetcher.makeRequest(){
    (result:AnyObject,err:NSError?)in
        if let error = err {
            //handleresult
        }else{
            //handle error
        }
}

Objective-C:
[fetcher makeRequest:^(idresult, NSError *err) {
    if(!err) {
        // handle result
    } else {
        // handle error
    }
}];

當然,有些自作聰明的人會問我,你這樣做,不就是把兩個block用if表達式的形勢合并成了一個block啊,好像并沒有什么用誒。他們覺得自己是個天才,直到我給他們看了下面的

Swift:
progressBar.startAnimating()
fetcher.makeRequest({
    result:AnyObject in 
    progressBar.stopAnimating()
    /*do something with result*/
},error:{
    err:NSError in
    /*為什么你這里要寫兩句一模一樣的代碼!*/
    progressBar.stopAnimating()
    /*do something with error*/
})
Objective-C:
[progressBar startAnimating];
[fetcher makeRequest:^(id result) {
    [progressBar stopAnimating];
    /* do something with result*/
} error:^(NSError *err) {
    /*為什么你這里要寫兩句一模一樣的代碼!*/
    [progressBar stopAnimating];
    /* Do something with error */
}];

5.效率

AVPlayer有一個回調(diào)是用作當前的播放時間改變時調(diào)用。這更像是一個過程而不是一個結(jié)果,所以根據(jù)第4點,我們應(yīng)該使用delegation。但是這個回調(diào)使用的卻是block,我猜這是因為效率原因,因為block可以一秒鐘被調(diào)用、回溯非常多次,而消息查找可能會比較慢。(作者這一點有待商榷,block通過壓棧的方式達到保存狀態(tài)和變量的目的,而delegate只是增加一個引用,理論上block的開銷要比delegate更大。)

?著作權(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)容