Android中Adapter和Bridge模式理解和應用

　　Android中Adapter和Bridge模式理解和應用

 

一 Adapter模式

意圖：

　　將一個類的介面轉換成客戶希望的另外一個介面。

Adapter模式使得原本由於介面不相容而不能在一起工作的那些類可以在一起工作。

適用性：

1. 使用一個已存在的類，而它的介面不符合你的要求；
2. 你想使用一些已經存在的子類，但是不可能對每一個都進行子類化以匹配他們的介面，而是使用對象適配器適配他們的父類介面；
3. 你想建立一個可以複用的類，該類可以與其他不相關的類或者不可預見的類（介面可能不一定相容的類）協同工作；

看看其結構圖：

 　　

　　　　

這是一個對象適配器結構圖；

　　其實類似這樣的類結構圖（一個類包含了另一個類的執行個體並使用其中的方法等）是很多的：

是不是只要具備這樣的結構都可以稱之為Adapter模式呢？

　　Adapter有兩種形式：對象適配器和類適配器。

 　　

　　　　

這是一個類適配器結構圖；

理解：

　　從繼承的角度來理解：Adapter既然能夠繼承了Adaptee，那麼可以認為Adapter就是一個Adaptee，

只有具備這樣的關係才可以繼承。但是對於Java中的介面可能不同，介面僅僅只是一些列方法聲明的集合。

但是如果一個類實現了某個介面XXX，我們說這個類是一個XXX，這樣似乎也是不合理的；介面實現是繼承也不是，

對Java的介面這個地方搞的不是很明白感覺有些不嚴密。

　　所以並不是具備了這樣的類結構都可以稱之為Adapter模式；Target和Adaptee之間的關係就是：

有一個新的Target想要使用Adaptee提供的介面，但是不能直接使用需要對其進行改造，於是進行擴充——Adapter模式。

　　如果Target是一個抽象類別，Adaptee也是一個抽象類別，那麼結果將是什麼樣子呢。

Adapter的目的就是為串連Target和Adaptee而生。

使之擴充的餘地變得更靈活更廣闊，那這還是Adapter模式嗎？暫且不管往下走。

　　下面通過學習Android中的AdapterView和Adapter對於 Adapter模式和Bridge模式的應用，

來理解Adapter模式和Bridge模式的應用上的經典設計執行個體。

 

二 Android中AdapterView顯示分析

看一下兩個類：

　　AdapterView（定義public abstract class AdapterView<T extends Adapter> extends ViewGroup，

　　　　　　<>是Java的泛型，表示T的類型必須是Adapter或其衍生類別）：抽象的ViewGroup類；

　　Adapter（public interface Adapter）：一個介面，是AdapterView和Data的橋樑。

看看一個ListView顯示需要的條件：

　　l  對象控制，屬性設定，事件派發處理

　　　　對於對象控制事件處理等屬於ViewGroup系統提供穩定的維護和控制方式，也會提供於我們介面去控制某些東西；

　　l  顯示布局控制項ViewItem，屬性等

　　　　對於顯示上所用的控制項布局，系統可能提供預設的，但是這裡我們使用自己的方式的去提供的可能性非常的大；

　　l  顯示資料Data

　　　　對於資料明顯只能是我們動態提供。

 

　　從代碼中可以看到AdapterView及其衍生類別是系統提供用於顯示控制，屬性設定，事件派發處理等，是顯示的控制中心；

　　Adapter衍生類別是提供顯示ViewItem和Data。具體瞭解可以看看原始碼。

　　這兩個一個是抽象類別一個是介面，所以需要做的就是串連這兩個類實現SubAdapterView的顯示——Adapter模式。

       下面學習一下ListView的大概結構及Adapter模式的應用。

 

三 Android中ListView的Adapter模式應用

       看一下ListView與ListAdapter的結構圖：

 

　　　　

 

　　　　

　　AbListView與LIstAdapter就是一個Adapter模式的應用。

　　AbListView：抽象類別；

　　ListAdapter：介面；

這還是Adapter模式嗎：

　　哈哈，到這裡我突然間茫然了，這還是一個Adapter模式嗎！怎麼看都更像是一個Bridge模式了。

看來理解還是不深刻啊，一是受名稱所嚴重欺騙，二是感覺結構實在和Adapter也很像（將兩個類通過對象適配一起工作滿足新的應用）。

搞了大半天我實在不想推翻自己無奈……設計模式學習過程中理解太膚淺了。

　　Adapter模式裡面的適用性所提到：你想使用一些已經存在的子類，但是不可能對每一個都進行子類化以匹配他們的介面。

但是可以適配它的父類介面。從這樣理解似乎也沒有錯啊：我們現在匹配的就是ListAdapter子類。

　　既然可以匹配父類適配子類，那麼為什麼又不可以匹配AblistView以適應子類呢？那這樣的結果就是兩邊都是抽象類別或者介面；

那這到底是哪一個模式呢。

       下面看一下Bridge模式的描述。

 

四 AbListView及ListAdapter和Bridge模式

　　先看看Bridge模式：

意圖：

　　將抽象部分與它的實現部分分離，使它們都可以獨立的變化。

　　抽象部分AbListView：衍生類別有ListView，GridView等；

　　實現部分ListAdapter：衍生類別有SimpleAdapter，CursorAdapter等；

　　滿足了定義中將抽象部分與實現部分分離的原則；

適用性：

       你不希望在抽象類別和它的實現部分之間有一個固定的綁定關係；

       類的抽象以及它的實現都應該通過產生子類的方法加以擴充；

       抽象類別的實現部分修改應該對客戶不產生影響；

       多個對象之間實現共用；

結構圖：

　　　　 

與AbListView和ListAdapter圖比較一下：

　　

　　　　

 

兩個圖結構是不是基本上就是一樣的呢？

Adapter與Bridge比較：

看看書中對於這兩個模式的比較：

　　Adapter模式用來協助無關的類協同工作，它通常是在系統設計完成之後才會被使用；

　　Bridge模式則是在系統設計開始的時候就被使用，它使得抽象介面和實現部分可以獨立的進行改變。

實際分析：

　　　　那麼此中的設計會是在設計完成之後發現不對勁，使用Adapter模式來協助這些類協同工作的嗎，

　　很明顯是在設計之前就已經確定了架構是要如此設計。而且AbListView和ListAdapter是不相關的類嗎？

　　明顯非常相關的兩個類，關係緊密結合親密無間。

Bridge模式要抽象和實現分離：

　　　　是因為其中存在兩個兩個變化的因素；抽象會有多個衍生類別，實現也會有多個依賴。

　　在AbListView和ListAdapter結構中：有多個AbListView衍生類別，也有多個ListAdapter實現。

　　不管是AblistView派生出新的類還是ListAdapter派生出新的類，都不會對對方產生影響，互相修改也不會互相影響，

　　AblistViewListAdapter之間是沒有固定的綁定關係，很容易通過派生新的子類對應用加以擴充。

　　

　　綜上所述，AbListView和ListAdapter結構設計應當屬於Bridge模式。

Adapter模式和Bridge同屬於結構性模式，結構圖看似差別很大，但其實這兩個模式給我感覺很相似，

通過這裡的學習有一些理解了其實是有很大不同的。