本篇文章介紹一種設(shè)計模式——命令模式。本篇文章內(nèi)容參考《JAVA與模式》之適配器模式,Android設(shè)計模式源碼解析之適配器(Adapter)模式。
一、適配器模式簡介
1.定義
適配器模式把一個類的接口變換成客戶端所期待的另一種接口,從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作。
2.定義闡述
適配器提供客戶類需要的接口,適配器的實現(xiàn)就是把客戶類的請求轉(zhuǎn)化為對適配者的相應(yīng)接口的調(diào)用。也就是說:當(dāng)客戶類調(diào)用適配器的方法時,在適配器類的內(nèi)部將調(diào)用適配者類的方法,而這個過程對客戶類是透明的,客戶類并不直接訪問適配者類。因此,適配器可以使由于接口不兼容而不能交互的類可以一起工作。這就是適配器模式的模式動機。
例如: 用電器做例子,筆記本電腦的插頭一般都是三相的,即除了陽極、陰極外,還有一個地極。而有些地方的電源插座卻只有兩極,沒有地極。電源插座與筆記本電腦的電源插頭不匹配使得筆記本電腦無法使用。這時候一個三相到兩相的轉(zhuǎn)換器(適配器)就能解決此問題,而這正像是本模式所做的事情。
二、適配器模式結(jié)構(gòu)
適配器模式有類的適配器模式和對象的適配器模式兩種不同的形式。
類適配器模式
類的適配器模式把適配的類的API轉(zhuǎn)換成為目標(biāo)類的API。
在上圖中可以看出,Adaptee類并沒有sampleOperation2()方法,而客戶端則期待這個方法。為使客戶端能夠使用Adaptee類,提供一個中間環(huán)節(jié),即類Adapter,把Adaptee的API與Target類的API銜接起來。Adapter與Adaptee是繼承關(guān)系,這決定了這個適配器模式是類的:
模式所涉及的角色有:
● 目標(biāo)(Target)角色:這就是所期待得到的接口。注意:由于這里討論的是類適配器模式,因此目標(biāo)不可以是類。
● 源(Adapee)角色:現(xiàn)在需要適配的接口。
● 適配器(Adaper)角色:適配器類是本模式的核心。適配器把源接口轉(zhuǎn)換成目標(biāo)接口。顯然,這一角色不可以是接口,而必須是具體類。
public interface Target {
/**
* 這是源類Adaptee也有的方法
*/
public void sampleOperation1();
/**
* 這是源類Adapteee沒有的方法
*/
public void sampleOperation2();
}
上面給出的是目標(biāo)角色的源代碼,這個角色是以一個JAVA接口的形式實現(xiàn)的。可以看出,這個接口聲明了兩個方法:sampleOperation1()和sampleOperation2()。而源角色Adaptee是一個具體類,它有一個sampleOperation1()方法,但是沒有sampleOperation2()方法。
public class Adaptee {
public void sampleOperation1(){}
}
適配器角色Adapter擴展了Adaptee,同時又實現(xiàn)了目標(biāo)(Target)接口。由于Adaptee沒有提供sampleOperation2()方法,而目標(biāo)接口又要求這個方法,因此適配器角色Adapter實現(xiàn)了這個方法。
public class Adapter extends Adaptee implements Target {
/**
* 由于源類Adaptee沒有方法sampleOperation2()
* 因此適配器補充上這個方法
*/
@Override
public void sampleOperation2() {
//寫相關(guān)的代碼
}
}
對象適配器模式
與類的適配器模式一樣,對象的適配器模式把被適配的類的API轉(zhuǎn)換成為目標(biāo)類的API,與類的適配器模式不同的是,對象的適配器模式不是使用繼承關(guān)系連接到Adaptee類,而是使用委派關(guān)系連接到Adaptee類。
從上圖可以看出,Adaptee類并沒有sampleOperation2()方法,而客戶端則期待這個方法。為使客戶端能夠使用Adaptee類,需要提供一個包裝(Wrapper)類Adapter。這個包裝類包裝了一個Adaptee的實例,從而此包裝類能夠把Adaptee的API與Target類的API銜接起來。Adapter與Adaptee是委派關(guān)系,這決定了適配器模式是對象的。
public interface Target {
/**
* 這是源類Adaptee也有的方法
*/
public void sampleOperation1();
/**
* 這是源類Adapteee沒有的方法
*/
public void sampleOperation2();
}
public class Adaptee {
public void sampleOperation1(){}
}
public class Adapter {
private Adaptee adaptee;
public Adapter(Adaptee adaptee){
this.adaptee = adaptee;
}
/**
* 源類Adaptee有方法sampleOperation1
* 因此適配器類直接委派即可
*/
public void sampleOperation1(){
this.adaptee.sampleOperation1();
}
/**
* 源類Adaptee沒有方法sampleOperation2
* 因此由適配器類需要補充此方法
*/
public void sampleOperation2(){
//寫相關(guān)的代碼
}
}
時序圖
三、類適配器和對象適配器的權(quán)衡
● 類適配器使用對象繼承的方式,是靜態(tài)的定義方式;而對象適配器使用對象組合的方式,是動態(tài)組合的方式。
● 對于類適配器,由于適配器直接繼承了Adaptee,使得適配器不能和Adaptee的子類一起工作,因為繼承是靜態(tài)的關(guān)系,當(dāng)適配器繼承了Adaptee后,就不可能再去處理 Adaptee的子類了。
● 對于對象適配器,一個適配器可以把多種不同的源適配到同一個目標(biāo)。換言之,同一個適配器可以把源類和它的子類都適配到目標(biāo)接口。因為對象適配器采用的是對象組合的關(guān)系,只要對象類型正確,是不是子類都無所謂。
● 對于類適配器,適配器可以重定義Adaptee的部分行為,相當(dāng)于子類覆蓋父類的部分實現(xiàn)方法。
● 對于對象適配器,要重定義Adaptee的行為比較困難,這種情況下,需要定義Adaptee的子類來實現(xiàn)重定義,然后讓適配器組合子類。雖然重定義Adaptee的行為比較困難,但是想要增加一些新的行為則方便的很,而且新增加的行為可同時適用于所有的源。
● 對于類適配器,僅僅引入了一個對象,并不需要額外的引用來間接得到Adaptee。
● 對于對象適配器,需要額外的引用來間接得到Adaptee。
建議盡量使用對象適配器的實現(xiàn)方式,多用合成/聚合、少用繼承。當(dāng)然,具體問題具體分析,根據(jù)需要來選用實現(xiàn)方式,最適合的才是最好的。
四、缺省適配器
缺省適配(Default Adapter)模式為一個接口提供缺省實現(xiàn),這樣子類型可以從這個缺省實現(xiàn)進行擴展,而不必從原有接口進行擴展。
當(dāng)不需要全部實現(xiàn)接口提供的方法時,可先設(shè)計一個抽象類實現(xiàn)接口,并為該接口中每個方法提供一個默認(rèn)實現(xiàn)(空方法),那么該抽象類的子類可有選擇地覆蓋父類的某些方法來實現(xiàn)需求,它適用于一個接口不想使用其所有的方法的情況。
五、Java中適配器模式的使用
JDK1.1 之前提供的容器有 Arrays,Vector,Stack,Hashtable,Properties,BitSet,其中定義了一種訪問群集內(nèi)各元素的標(biāo)準(zhǔn)方式,稱為 Enumeration(列舉器)接口。
Vector v=new Vector();
for (Enumeration enum =v.elements(); enum.hasMoreElements();) {
Object o = enum.nextElement();
processObject(o);
}
JDK1.2 版本中引入了 Iterator 接口,新版本的集合對(HashSet,HashMap,WeakHeahMap,ArrayList,TreeSet,TreeMap, LinkedList)是通過 Iterator 接口訪問集合元素。
List list=new ArrayList();
for(Iterator it=list.iterator();it.hasNext();)
{
System.out.println(it.next());
}
這樣,如果將老版本的程序運行在新的 Java 編譯器上就會出錯。因為 List 接口中已經(jīng)沒有 elements(),而只有 iterator() 了。那么如何將老版本的程序運行在新的 Java 編譯器上呢? 如果不加修改,是肯定不行的,但是修改要遵循“開-閉”原則。我們可以用 Java 設(shè)計模式中的適配器模式解決這個問題。
public class NewEnumeration implements Enumeration
{
Iterator it;
public NewEnumeration(Iterator it)
{
this.it=it;
}
public boolean hasMoreElements()
{
return it.hasNext();
}
public Object nextElement()
{
return it.next();
}
public static void main(String[] args)
{
List list=new ArrayList();
list.add("a");
list.add("b");
list.add("C");
for(Enumeration e=new NewEnumeration(list.iterator());e.hasMoreElements();)
{
System.out.println(e.nextElement());
}
}
}
NewEnumeration 是一個適配器類,通過它實現(xiàn)了從 Iterator 接口到 Enumeration 接口的適配,這樣我們就可以使用老版本的代碼來使用新的集合對象了。
六、Android中適配器模式的使用
在開發(fā)過程中,ListView的Adapter是我們最為常見的類型之一。一般的用法大致如下:
// 代碼省略
ListView myListView = (ListView)findViewById(listview_id);
// 設(shè)置適配器
myListView.setAdapter(new MyAdapter(context, myDatas));
// 適配器
public class MyAdapter extends BaseAdapter{
private LayoutInflater mInflater;
List<String> mDatas ;
public MyAdapter(Context context, List<String> datas){
this.mInflater = LayoutInflater.from(context);
mDatas = datas ;
}
@Override
public int getCount() {
return mDatas.size();
}
@Override
public String getItem(int pos) {
return mDatas.get(pos);
}
@Override
public long getItemId(int pos) {
return pos;
}
// 解析、設(shè)置、緩存convertView以及相關(guān)內(nèi)容
@Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder holder = null;
// Item View的復(fù)用
if (convertView == null) {
holder = new ViewHolder();
convertView = mInflater.inflate(R.layout.my_listview_item, null);
// 獲取title
holder.title = (TextView)convertView.findViewById(R.id.title);
convertView.setTag(holder);
} else {
holder = (ViewHolder)convertView.getTag();
}
holder.title.setText(mDatas.get(position));
return convertView;
}
}
我們知道,作為最重要的View,ListView需要能夠顯示各式各樣的視圖,每個人需要的顯示效果各不相同,顯示的數(shù)據(jù)類型、數(shù)量等也千變?nèi)f化。那么如何隔離這種變化尤為重要。
Android的做法是增加一個Adapter層來應(yīng)對變化,將ListView需要的接口抽象到Adapter對象中,這樣只要用戶實現(xiàn)了Adapter的接口,ListView就可以按照用戶設(shè)定的顯示效果、數(shù)量、數(shù)據(jù)來顯示特定的Item View。
通過代理數(shù)據(jù)集來告知ListView數(shù)據(jù)的個數(shù)( getCount函數(shù) )以及每個數(shù)據(jù)的類型( getItem函數(shù) ),最重要的是要解決Item View的輸出。Item View千變?nèi)f化,但終究它都是View類型,Adapter統(tǒng)一將Item View輸出為View ( getView函數(shù) ),這樣就很好的應(yīng)對了Item View的可變性。
那么ListView是如何通過Adapter模式 ( 不止Adapter模式 )來運作的呢 ?我們一起來看一看。
ListView繼承自AbsListView,Adapter定義在AbsListView中,我們看一看這個類。
public abstract class AbsListView extends AdapterView<ListAdapter> implements TextWatcher,
ViewTreeObserver.OnGlobalLayoutListener, Filter.FilterListener,
ViewTreeObserver.OnTouchModeChangeListener,
RemoteViewsAdapter.RemoteAdapterConnectionCallback {
ListAdapter mAdapter ;
// 關(guān)聯(lián)到Window時調(diào)用的函數(shù)
@Override
protected void onAttachedToWindow() {
super.onAttachedToWindow();
// 代碼省略
// 給適配器注冊一個觀察者。
if (mAdapter != null && mDataSetObserver == null) {
mDataSetObserver = new AdapterDataSetObserver();
mAdapter.registerDataSetObserver(mDataSetObserver);
// Data may have changed while we were detached. Refresh.
mDataChanged = true;
mOldItemCount = mItemCount
// 獲取Item的數(shù)量,調(diào)用的是mAdapter的getCount方法
mItemCount = mAdapter.getCount();
}
mIsAttached = true;
}
/**
* 子類需要覆寫layoutChildren()函數(shù)來布局child view,也就是Item View
*/
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
super.onLayout(changed, l, t, r, b);
mInLayout = true;
if (changed) {
int childCount = getChildCount();
for (int i = 0; i < childCount; i++) {
getChildAt(i).forceLayout();
}
mRecycler.markChildrenDirty();
}
if (mFastScroller != null && mItemCount != mOldItemCount) {
mFastScroller.onItemCountChanged(mOldItemCount, mItemCount);
}
// 布局Child View
layoutChildren();
mInLayout = false;
mOverscrollMax = (b - t) / OVERSCROLL_LIMIT_DIVISOR;
}
// 獲取一個Item View
View obtainView(int position, boolean[] isScrap) {
isScrap[0] = false;
View scrapView;
// 從緩存的Item View中獲取,ListView的復(fù)用機制就在這里
scrapView = mRecycler.getScrapView(position);
View child;
if (scrapView != null) {
// 代碼省略
child = mAdapter.getView(position, scrapView, this);
// 代碼省略
} else {
child = mAdapter.getView(position, null, this);
// 代碼省略
}
return child;
}
}
通過增加Adapter一層來將Item View的操作抽象起來,ListView等集合視圖通過Adapter對象獲得Item的個數(shù)、數(shù)據(jù)元素、Item View等,從而達(dá)到適配各種數(shù)據(jù)、各種Item視圖的效果。
因為Item View和數(shù)據(jù)類型千變?nèi)f化,Android的架構(gòu)師們將這些變化的部分交給用戶來處理,通過getCount、getItem、getView等幾個方法抽象出來,也就是將Item View的構(gòu)造過程交給用戶來處理,靈活地運用了適配器模式,達(dá)到了無限適配、擁抱變化的目的。
七、適配器模式的優(yōu)缺點
適配器模式的優(yōu)點
更好的復(fù)用性
系統(tǒng)需要使用現(xiàn)有的類,而此類的接口不符合系統(tǒng)的需要。那么通過適配器模式就可以讓這些功能得到更好的復(fù)用。
更好的擴展性
在實現(xiàn)適配器功能的時候,可以調(diào)用自己開發(fā)的功能,從而自然地擴展系統(tǒng)的功能。
適配器模式的缺點
過多的使用適配器,會讓系統(tǒng)非常零亂,不易整體進行把握。比如,明明看到調(diào)用的是A接口,其實內(nèi)部被適配成了B接口的實現(xiàn),一個系統(tǒng)如果太多出現(xiàn)這種情況,無異于一場災(zāi)難。因此如果不是很有必要,可以不使用適配器,而是直接對系統(tǒng)進行重構(gòu)。