引言

　　在項目開發(fā)中，有時候會遇到這樣的一種情景：需要使用以前開發(fā)的“一些現(xiàn)存的對象”，但是新環(huán)境中要求的接口是這些現(xiàn)存對象所不滿足的。怎樣應對這種遷移的需求？使得可以復用這些對象，以滿足新的應用環(huán)境，這就是適配器（Adapter）所要解決的問題。

定義

　　“將一個類的接口轉換成客戶希望的另外一個接口。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作?！?/p>

最初的定義出現(xiàn)于《設計模式》(Addison-Wesley,1994)。
　　這個定義應該很好理解，生活中也到處充滿著適配器模式的應用，比如說我們手機的充電器：手機是不能在220V電源上直接充電的，充電器將電壓轉換成手機需要的電壓后，手機才可以正常充電，這個充電器就起到了適配的作用。

結構圖

　　有兩種實現(xiàn)適配器模式的方式。第一種是通過繼承來適配兩個接口，這稱為類適配器。在Gof介紹設計模式的書中，類適配器是通過多重繼承來實現(xiàn)的。書中使用的語言是C++，它并沒有C#的接口或OC的協(xié)議這樣的語法，一切都是類。在OC中，類可以實現(xiàn)協(xié)議，同時又繼承父類，達到C++多繼承的效果。要在OC中實現(xiàn)類適配器，首先需要有定義了客戶端要使用的一套行為的協(xié)議，然后要用具體的適配器類來實現(xiàn)這個協(xié)議。適配器類同時也要繼承被適配者。類適配器結構圖如下所示：

從圖中可以看到，Adapter是一個Target類型，同時也是Adaptee類型。它重載了Target的request方法，沒有重載Adaptee中的specificRequest方法，而是在Adapter的request方法的實現(xiàn)中，調用父類的specificRequest方法。只有當Target是協(xié)議而不是類時，類適配器才能夠用OC來實現(xiàn)，因為OC中是沒有多重繼承的。
　　實現(xiàn)適配器模式的第二種方式稱為對象適配器。與類適配器不同，對象適配器不繼承被適配者，而是組合了一個對它的引用。對象適配器結構圖如下所示：

　從兩個結構圖可以看到，Target和Adapter的關系相同，Adapter和Adaptee之間的關系，由繼承變成了關聯(lián)。這種關系下，Adapter需要保持一個對Adaptee的引用。在request方法中，Adapter發(fā)送[_adaptee specificRequest]消息給Adaptee，以完成客戶端的請求。

　　很顯然，OC中常用的委托(Delegate)模式屬于對象適配器。以常用的UITableViewDelegate為例，我這里先畫出它的結構圖，如下所示：

　UITableView(對象適配器中的Client角色)處理選中行事件時，消息會傳遞給UITableViewDelegate(對象適配器中Target角色)，然后調用MyViewController(對象適配器中Adapter角色)里面的- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath方法來進行處理，在MyViewController的這個方法中，我們會調用其他對象(比如說我們可能會調用詳情DetailViewController對象來跳轉到詳情頁面)來處理該消息。

實例
Target類接口

小結

1.適配器模式主要應用于“希望復用一些現(xiàn)存的類，但是接口又與復用環(huán)境要求不一致的情況”，在遺留代碼復用、類庫遷移等方面非常有用。

2.適配器模式有對象適配器和類適配器兩種形式的實現(xiàn)結構，但是類適配器采用“多繼承”的實現(xiàn)方式，帶來了不良的高耦合，所以一般不推薦使用，另外，OC中也不支持多重繼承。對象適配器采用“對象組合”的方式，更符合松耦合規(guī)范。

在以下各種情況下可以考慮使用適配器模式：

1.需要使用一個已經存在的類，而它的接口不符合新環(huán)境的規(guī)范。
2.想創(chuàng)建一個可以復用的類，該類可以與其他不相關的類或不可預見的類（即那些接口可能不一定兼容的類）協(xié)同工作。

最新評論