近年物件導向程式設計中有個常見的名稱：Delegate（委派）。假設有個主要物件 A ，需透過某物件 B 處理一些事情（例如解壓縮、網路下載...等工作），視 B 處理到某些情況時將狀況回報給 A 之後，A 再進行後續處理，那麼就會設定 B 的委派角色為 A。A 多半是應用程序中主要的畫面，B 則是自定的程序，在開發應用的實例上，類似 B 的角色有很多個在同時運作，按照一般教學的寫法，主畫面 A 就會負責接收一大堆委派結果，程式就會顯得又臭又長。
不過有些接收回來至 A 的資料結果其實並不是那麼複雜，只是要顯示在畫面罷了，為了這些小工作就進行 Delegate 指派動作，這些小工作累積一多起來，打字、爬蟲工作真的很累人。在 iOS 的 Object-C 語法中，其實有個相對簡單、但更加抽象的方式，可以大幅簡化這些流程：使用 Blocks 方法。Blocks 是 iOS 4 新增的語法特性，從近年來新增的 iOS API 觀察得知，使用 Blocks 的 API 越來越多，蘋果越來越傾向於要求開發者使用 Blocks 來處理相關程序， 因為 Blocks 寫起來有個好處，可以很直接在程式碼內把工作交辦出去之後，直接撰寫接下來要做的事情，這點就比使用 Delegate 方式直覺太多了。我簡單弄了一個範例在 Github，為方便閱讀已經程式碼精簡到最少，但也因此可能有其他問題，所以該寫法不適合商品實作。此範例表示使用 Delegate 與 Block 兩種不同的方法，也能達到相同結果的展示。
從範例中得知，Delegate 方法必須建立與設定委派對象，以及建立 protocol 協議，在適當的地方宣告之後，才能讓所有的動作正常串聯起來。Block 方法就簡單多了，兩行搞定，不需再做其他設定或宣告。
結果看起來相同，但意思不太一樣：Delegate 的方法是，主畫面程序 A 呼叫 B 程序運行，並成為 B 的委派角色之後，B 將結果回調至委派角色 A，A 再把結果顯示在主畫面上。至於 Block 方法，就是 A 把「在畫面顯示結果」的方法複製給 B 程序，然後 B 程序運行之後，再執行從 A 複製過來的「在畫面顯示結果」的程序，所以運行程序的角色為 B。
這個 Block 的方法嘛～怎麼感覺跟慣老闆的作風有點像啊？
留言列表
{{ article.title }}
IoT 物聯網 (2)