今天，讓我們跟隨昨天的步伐，和南昌APP開發公司--百恒網絡一起學習ios設計模式之委托模式。

委托模式

委托模式從GoF裝飾(Decorator)模式、適配器(Adapter)模式和模板方法(Template Method)模式等演變而來。幾乎每一個應用都會或多或少地用到委托模式。不只是Cocoa Touch框架，在Cocoa框架中，委托模式也得到了廣泛的應用。

2.1 問題提出

對于應用生命周期的非運行狀態應用啟動場景，我們把從點擊圖標到啟動第一個界面的過程細化了一下，具體如圖所示。

假設這一系列的處理都是在上帝類 UIApplication 中完成的之所以叫“上帝類”(god class)，是因為它“無所不能”、“包含所有”。 在面向對象的軟件設計中，“上帝類”不是很友好，需要重構。在編程的過程中，要盡量避免使用上帝類，因為上帝類是高耦合的，職責不清，難以維護。我們需要“去除上帝類”，把看似功能很強且很難維護的類，按照職責將它的屬性或方法分派到各自的類中或分解成功能明確的類。

幸運的是，蘋果沒有把 UIApplication 類設計成“上帝類”，而是將它們分割到兩個不同的角色類中：其中一個扮演框架類角色，框架類具有通用、可重復使用、與具體應用無關等特點;另一個扮演應用相關類的角色，應用相關類與具體應用有關。由于受到框架類的控制，應用相關類常常被設計為“協議”，在Java中稱為“接口”。開發人員需要在具體的應用中實現這個“協議”。

如圖所示，將一些功能提取出來放在application:didFinishLaunchingWithOptions: 和 applicationDidBecomeActive: 方法中完成，定義在UIApplicationDelegate 協議中，這樣 UIApplication 類就變成了框架類。

非運行狀態應用啟動場景的流程圖

去“上帝”化的非運行狀態啟動場景流程圖

在具體使用時，需要實現 UIApplicationDelegate 協議。HelloWorld應用的類圖如圖所示。

去“上帝”化的HelloWorld應用類圖

UIApplication 不直接依賴于 AppDelegate 類，而是依賴于 UIApplicationDelegate 協議，這在面向對象軟件設計原則中叫做“面向接口的編程”。 AppDelegate 類實現協議UIApplicationDelegate ，它是委托類。

委托是為了降低一個對象的復雜度和耦合度，使其能夠更具通用性而將其中一些處理置于委托對象中的編碼方式。通用類因為通用性(與具體應用的無關性)而變為框架類，框架類保持委托對象的指針，并在特定時刻向委托對象發送消息。消息可能只是通知委托對象做一些事情，也可能是對委托對象進行控制。

2.2 實現原理

下面我們通過一個案例介紹委托設計模式的實現原理和應用場景，重新繪制的委托設計模式類圖如圖所示。

委托設計模式類圖

古希臘有一位哲學家，他畢生只做三件事情：“睡覺”“吃飯”和“工作”。為了更好地生活，提高工作效率，他會找一個徒弟，把這些事情委托給徒弟做。然而要成為他的徒弟，需要實現一個協議，協議要求能夠處理“睡覺”“吃飯”和“工作”的問題。三者的關系如類圖所示。

委托設計模式哲學家案例類圖(左圖為Swift版，右圖為Objective-C版)

從圖中所示的哲學家類圖中可以看到，通用類( Philosopher )就是哲學家，它通過 delegate 屬性保持委托對 象 ( ViewController ) 的 引 用 ， 委 托 對 象 ( ViewController ) 就 是 哲 學 家 的 徒 弟 ， 它 實 現 了 協 議PhilosopherDelegate 。 PhilosopherDelegate 規定了3個方法： sleep 、 eat 和 work 方法。

下面我們看看實現代碼，委托協議PhilosopherDelegate的代碼如下：

可以看到，委托協議 PhilosopherDelegate 定義了3個方法。它的實現類是 ViewController ，相關代碼如下：

委托對象如何與通用類建立引用關系呢?這通過 viewDidLoad 方法中的 tom.delegate = self 語句來指定。一般情況下，通用類由框架直接提供。在這個例子中，我們根據需要自己實現通用類 Philosopher ，相關代碼如下：

在上述代碼中，第①行用于定義 delegate 屬性。

比較說明 在Swift版本中， delegate 屬性的類型是 PhilosopherDelegate? ，它可以保存委托對象的引用，其中 ?號表示 delegate 可以為 nil 。在Objective-C版本中， delegate 屬性的類型是 id ，它可以保存委托對象的引用，其中屬性 weak 說明是“弱引用”。這里使用弱引用方式是為了防止內存

引用計數增加而導致委托對象無法釋放的問題。

為了測試我們在 Philosopher 中通過 NSTimer 每3秒發出一個，依次向委托對象發出消息 sleep 、 eat 和 work 。self.delegate 事實上是 ViewController 對象，所以第②行代碼調用 ViewController 中的 sleep 方法。

2.3 應用案例

我們以 UITextFieldDelegate 為例來說明一下委托的用法。 UITextFieldDelegate 是控件UITextField的委托，它主要負責響應控件事件或控制其他對象。除了UITextField，WebView和UITableView等控件也有相應的委托對象。

打開 UITextFieldDelegate 的API文檔(如圖所示)，可以發現其中有4個與編輯有關的方法，還有3個其他方法。

UITextFieldDelegate 的API文檔

這里我們重點介紹在編輯過程中消息的發送以及UITextField控件與 UITextFieldDelegate 委托對象之間的交互過程，如圖所示。

UITextField控件與 UITextFieldDelegate 委托對象之間的交互過程

在文本框開始編輯前后，會分別發出消息textFieldShouldBeginEditing: 和textFieldDidBeginEditing: ，編輯結束前后會分別發出消息textFieldShouldEndEditing: 和 textFieldDidEndEditing: 。

注意 委托消息命名有一定的約定性，如果是UITextField發出的消息，就以 textField 開頭，后面跟3個詞之一—— Should 、 Will 或 Did 。在使用 Should 消息時，應該返回一個布爾值，這個返回值用于確定委托是否會響應消息;當使用 Will 后綴時，沒有返回值，表示改變前要做的事情;當使用 Did 后綴時，也沒有返回值，表示改變之后要做的事情。這3種方法都會把發送消息的對象以參數的形式回傳回來，例如textFieldShouldBeginEditing(textField: UITextField) 消息中的參數 textField 。

為了演示文本框編輯前后發生了什么，我們需要編寫一個簡單的文本框工程，如圖所示，其中界面中只包含一個文本框，然后為文本框定義輸出口。最后添加Auto Layout所有約束。

文本框工程界面

我們在視圖控制器 ViewController 中實現 UITextFieldDelegate ，相關代碼如下：

在 viewDidLoad 方法中，第①行代碼極為重要，是將當前視圖控制器分配給文本框委托對象。除了通過編程實現分配委托對象外，我們也可以通過Interface Builder在故事板中連線分配委托對象。如圖所示，打開故事板文件，右擊文本框控件，從彈出的快捷菜單中，將位于Outlets(輸出口)下面的delegate后面的圓圈用鼠標拖曳到View Controller上，然后釋放鼠標。

定義委托輸出口

運行代碼，輸出的日志如下：

輸入完成后，點擊return鍵，關閉鍵盤，結束編輯狀態，此時日志中的輸出結果如下：

其中 textFieldShouldReturn: 是點擊return鍵時發出的消息，我們借助該消息通過 textField.resignFirst-Responder() 方法關閉鍵盤。

對于一些更復雜的控件(如UITableView)，除了需要實現委托協議外，還需要實現數據源協議。數據源與委托一樣，都是委托設計模式的具體應用，委托對象主要對控件對象的事件和狀態變化作出響應，而數據源對象是為控件對象提供數據。

本文僅限內部技術人員學習交流,不得作于其他商業用途.希望此文對廣大技人員有所幫助。文章出自:南昌APP開發公司-百恒網絡。如有需要，百恒網絡歡迎隨時咨詢。