一般在這種情況下，我喜歡問我自己：“如果問題交給Apple，他會怎么做呢?”當然，我們都知道Apple肯定知道怎么做，因為從某一層面上看，Apple的文檔就是一本用來指導我們?nèi)绾问褂迷O計模式的指導書。

　　因此我們需要去研究一下Apple分別是在什么情況下使用delegate和block，如果我們發(fā)現(xiàn)了Apple做這種選擇的套路，我們就可以構(gòu)建出一些規(guī)則，可以幫助在我們在自己的代碼中做相同選擇。

　　要找出Apple使用delegate的場景很簡單，我們只要搜索官方文檔中的“delegate”，就會獲取到很多使用delegation的類。

　　但是搜索Apple中有關使用blocks的文檔就有點困難了，因為我們不能直接搜索文檔中的“^” 。然而，Apple聲明方法時有很好的命名習慣(這也是我們精通iOS開發(fā)的一項必備技能)。例如：一個以NSString為參數(shù)的方法，方法的selector就會有String字眼，像initWithString;dateFromString;StartSpeaingString。

　　當Apple的方法使用block，這個方法將會有“Handler”,“Completion”或者簡單的“Block”作為selector;因此我們可以在標準的iOS API文檔中搜索這些關鍵詞，用以構(gòu)建一個可信任的block用例列表。

　　1.大多數(shù)delegate PRotocols 都擁有幾個消息源。

　　以我正在看的GKMatch為例(A GKMatch object provides a peer-to-peer network between a group of devices that are connected to Game Center，是iOS API中用來提供一組設備連接到Game Center點對點網(wǎng)絡的對象)。從這個類中可以看到消息的來源分別是：當從其他玩家那接收到數(shù)據(jù)、當玩家切換了狀態(tài)、當發(fā)生錯誤或者當一個玩家應該被重新邀請。這些都是不同的事件。如果Apple在這里使用block，那么可能會有以下兩種解決方式：

　　可以對應每一個事件注冊相應的block，顯然這種方式是不合理的。( If someone writes a class that does this in Objective-C, they are probably an asshole.)

　　1創(chuàng)建一個可以接受任何可能輸入的block

　　void (^matchBlock)(GKMatchEvent eventType, Player *player, NSData *data, NSError *err);

　　很明顯這種方式既不簡便又不易讀，所以你可能從未看過這樣的解決方案。如果你看過這樣的解決方式，但是這顯然是一個糟糕至極的代碼行，你不會有精力去維護這個。

　　因此，我們可以得出一個結(jié)論：如果對象有超過一個以上不同的事件源，使用delegation。

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

　　由于一個對象只能有一個delegate，而且它只能與這個delegate通信。讓我們看看CLLocationManager 這個類，當發(fā)現(xiàn)地理位置后，location manager 只會通知一個對象(有且只有一個)。當然，如果我們需要更多的對象去知道這個更新，我們最好創(chuàng)建其他的location manager。

　　這里有的人可能想到，如果CLLocationManager是個單例呢?如果我們不能創(chuàng)建CLLocationManager的其他實例，就必須不斷地切換delegate指針到需要地理數(shù)據(jù)的對象上(或者創(chuàng)建一個只有你理解的精密的廣播系統(tǒng))。因此，這樣看起來，delegatetion在單例上沒有多大意義。

　　關于這點，最好的印證例子就是UIAccelerometer。在早期版本的iOS中，單例的 accelerometer 實例有一個delegate，導致我們必須偶爾切換一下。這個愚蠢的問題在之后的IOS版本被修改了，現(xiàn)在，任意一個對象都可以訪問CMMotionManager block，而不需要阻止其他的對象來接收更新。

　　因此，我們可以得出另一個結(jié)論：“如果一個對象是單例，不要使用delegation”。

　　3.一般的delegate方法會有返回值

　　如果你觀察一些delegate方法(幾乎所有的dataSource方法)都有一個返回值。這就意味著delegating對象在請求某些東西的state(對象的值，或者對象本身)，而一個block則可以合理地包含state或者至少是推斷state，因此block真正是對象的一個屬性。

　　讓我們思考一下一個有趣的場景，如果向一個block提問：“What do you think about Bob?”。block可能會做兩件事情：發(fā)送一個消息去捕獲對象并詢問這個對象怎么看待Bob，或者直接返回一個捕獲的值。如果返回了一個對象的響應，我們應該越過這個block直接獲取這個對象。如果它返回了一個捕獲的值，那么這應該是一個對象的屬性。

　　從以上的觀察，我們可以得出結(jié)論：如果對象的請求帶有附加信息，更應該使用delegation

　　4.過程 vs 結(jié)果(Process vs. Results)

　　如果查看NSURLConnectionDelegate 以及 NSURLConnectionDataDelegate，我們在可以protocol中看到這樣的消息：我將要做什么(如： willSendRequest，將要發(fā)送請求)、到目前為止我知道的信息(如：canAuthenticateAgainstProtectionSpace)、我已經(jīng)完成這些啦( didReceiveResponse，收到請求的回復，即完成請求)。這些消息組成一個流程，而那些對流程感興趣的delegate將會在每一步得到相應的通知。

　　當我們觀察handler和完整的方法時，我們發(fā)現(xiàn)一個block包含一個響應對象和一個錯誤對象。顯然這里沒有任何有關“我在哪里，我正在做什么的”的交互。

　　因此我們可以這樣認為，delegate的回調(diào)更多的面向過程，而block則是面向結(jié)果的。如果你需要得到一條多步進程的通知，你應該使用delegation。而當你只是希望得到你請求的信息(或者獲取信息時的錯誤提示)，你應該使用block。(如果你結(jié)合之前的3個結(jié)論，你會發(fā)現(xiàn)delegate可以在所有事件中維持state，而多個獨立的block確不能)

　　從上面我們可以得出兩個關鍵點。首先，如果你使用block去請求一個可能失敗的請求，你應當只使用一個block。我們可以看到如下的代碼：

　　[fetcher makeRequest:^(id result) {

　　// do something with result

　　} error:^(NSError *err) {

　　// Do something with error

　　}];

　　上面代碼的可讀性明顯比下面block的可讀性差(作者說這個是他不謙虛的觀點，其實個人認為沒有那么嚴重)

　　[fetcher makeRequest:^(id result, NSError *err) {

　　if(!err) {

　　// handle result

　　} else {

　　// handle error

　　}

　　}];