對于開發(fā)人員來說徙硅，設(shè)計模式有時候就是一道坎即碗，但是設(shè)計模式又非常有用，過了這道坎涝桅，它可以讓你水平提高一個檔次拜姿。而在android開發(fā)中，必要的了解一些設(shè)計模式又是必須的冯遂，因為設(shè)計模式在Android源碼中蕊肥，可以說是無處不在。對于想系統(tǒng)的學(xué)習(xí)設(shè)計模式的同學(xué)蛤肌，這里推薦一本書壁却，《大話設(shè)計模式》。
Android常用設(shè)計模式系列：
面向?qū)ο蟮幕A(chǔ)特征
面向?qū)ο蟮脑O(shè)計原則
單例模式
模板模式
適配器模式
工廠模式
代理模式
原型模式
策略模式
Build模式
觀察者模式
裝飾者模式
中介模式
門面模式
適配器模式
適配器模式是非常常見的設(shè)計模式之一裸准，寫個筆記展东，記錄一下我的學(xué)習(xí)過程和心得。
首先了解一些適配器模式的定義炒俱。
將一個類的接口變換成客戶端所期待的另一種接口盐肃，從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作。
齋看定義权悟，也是有點(diǎn)難理解的砸王，還是要結(jié)合一個列子來進(jìn)行講，有助于我們更好的理解峦阁。
生活中的手機(jī)充電器就是一個適配器的例子谦铃，手機(jī)一般都是在5V的電壓下進(jìn)行充電，但是外部的電壓都是220V榔昔，那怎么辦驹闰，這就需要充電器去適配了，將220V的電壓轉(zhuǎn)換為5V撒会。
根據(jù)適配器模式的定義嘹朗，我們知道有三個角色參與了其中的工作：
- Adapter(適配器接口):即目標(biāo)角色，定義把其他類轉(zhuǎn)換為何種接口诵肛，也就是我們期望的接口屹培。
- Adaptee(被適配角色):即源角色，一般是已存在的類曾掂，需要適配新的接口惫谤。
- ConcreteAdapter(具體適配器):實現(xiàn)適配器接口壁顶，把源角色接口轉(zhuǎn)換為目標(biāo)角色期望的接口珠洗。
那么，我們就開始實現(xiàn)吧
1. 創(chuàng)建適配器接口
現(xiàn)在我們需要定義一個220V轉(zhuǎn)換成5V的接口：
interface Adapter {//適配器類
int convert_5v();//裝換成5V
}
2. 創(chuàng)建被適配角色
被適配角色若专，一般是已存在的類许蓖，需要適配新的接口。生活中的220V電源無處不在：
public class Electric {// 電源
public int output_220v() {//輸出220V
return 220;
}
}
3. 創(chuàng)建具體適配器
我們需要一個具體適配器，這個適配器就是變壓器膊爪，能夠?qū)?20V轉(zhuǎn)為5V輸出：
public class PhoneAdapter implements Adapter {//手機(jī)適配器類
private Electric mElectric;//適配器持有源目標(biāo)對象
public PhoneAdapter(Electric electric) {//通過構(gòu)造方法傳入對象
mElectric = electric;
}
@Override
public int convert_5v() {
System.out.println("適配器開始工作：");
System.out.println("輸入電壓：" + mElectric.output_220v());
System.out.println("輸出電壓：" + 5);
return 5;
}
}
4. 客戶端測試：
public void test() {
Electric electric = new Electric();
System.out.println("默認(rèn)電壓：" + electric.output_220v());
Adapter phoneAdapter = new PhoneAdapter(electric);//傳遞一個對象給適配器
System.out.println("適配轉(zhuǎn)換后的電壓：" + phoneAdapter.convert_5v());
}
輸出結(jié)果：
默認(rèn)電壓：220
適配器開始工作：
輸入電壓：220
輸出電壓：5
適配轉(zhuǎn)換后的電壓：5
OK自阱，這樣就完成了一個適配器模式的實現(xiàn)。
這里實現(xiàn)的例子只是適配器模式其中的一種米酬，其實適配器模式分為
對象適配器模式
類適配器模式
這里我們講的是對象適配器的實現(xiàn)沛豌，類適配器的原理差不多的，只是類適配器模式?jīng)]什么優(yōu)勢赃额，用得比較少加派，這里就不做詳細(xì)講解了。
接下來把他們做一下對比：
- 類適配器采用了繼承的方式來實現(xiàn);而對象適配器是通過傳遞對象來實現(xiàn)跳芳，這是一種組合的方式芍锦。
- 類適配器由于采用了繼承，可以重寫父類的方法;對象適配器則不能修改對象本身的方法等飞盆。
- 適配器通過繼承都獲得了父類的方法娄琉，客戶端使用時都會把這些方法暴露出去，增加了一定的使用成本;對象適配器則不會吓歇。
- 類適配器只能適配他的父類孽水，這個父類的其他子類都不能適配到;而對象適配器可以適配不同的對象，只要這個對象的類型是同樣的照瘾。
- 類適配器不需要額外的引用;對象適配器需要額外的引用來保存對象匈棘。
廣泛應(yīng)用
適配器模式在android中的應(yīng)用非常廣，最常見的ListView析命、GridView主卫、RecyclerView等的Adapter。而鹃愤，我們經(jīng)常使用的ListView就是一個典范簇搅。
在使用ListView時，每一項的布局和數(shù)據(jù)都不一樣软吐，但是最后輸出都可以看作是一個View瘩将，這就對應(yīng)了上面的適配器模式應(yīng)用場景的第三條：需要一個統(tǒng)一的輸出接口，而輸入端的接口不可預(yù)知凹耙。下面我們來看看ListView中的適配器模式姿现。
首先我們來看看一般我們的Adapter類的結(jié)構(gòu)
class Adapter extends BaseAdapter {
private List<String> mDatas;
public Adapter(List<String> datas) {
mDatas = datas;
}
@Override
public int getCount() {
return mDatas.size();
}
@Override
public long getItemId(int position) { return position; }
@Override
public Object getItem(int position) { return mDatas.get(position);}
@Override
public View getView(int position, View convertView, ViewGroup parent) {
if (convertView == null) {
//初始化View
}
//初始化數(shù)據(jù)
return convertView;
}
}
可以看出Adapter里面的接口主要是getCount()返回子View的數(shù)量，以及getView()返回我們填充好數(shù)據(jù)的View肖抱，ListView則通過這些接口來執(zhí)行具體的布局备典、緩存等工作咪辱。下面我們來簡單看看ListView的實現(xiàn)饲嗽。
首先這些getCount()等接口都在一個接口類Adapter里
public interface Adapter {
//省略其他的接口
int getCount();
Object getItem(int position);
long getItemId(int position);
View getView(int position, View convertView, ViewGroup parent);
//省略其他的接口
}
中間加了一個過渡的接口ListAdapter
public interface ListAdapter extends Adapter {
//接口省略
}
我們在編寫我們自己的Adapter時都會繼承一個BaseAdapter胡诗，我們來看看BaseAdapter
public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter {
//BaseAdapter里面實現(xiàn)了ListAdapter的接口以及部分Adapter中的接口
//而像getCount()以及getView()這些接口則需要我們自己去實現(xiàn)
}
ListView的父類AbsListView中有ListAdapter接口，通過這個接口來調(diào)用getCount()等方法獲取View的數(shù)量等
public abstract class AbsListView extends AdapterView<ListAdapter> implements TextWatcher,
ViewTreeObserver.OnGlobalLayoutListener, Filter.FilterListener,
ViewTreeObserver.OnTouchModeChangeListener,
RemoteViewsAdapter.RemoteAdapterConnectionCallback {
/**
* The adapter containing the data to be displayed by this view
*/
ListAdapter mAdapter;
@Override
protected void onAttachedToWindow() {
super.onAttachedToWindow();
final ViewTreeObserver treeObserver = getViewTreeObserver();
treeObserver.addOnTouchModeChangeListener(this);
if (mTextFilterEnabled && mPopup != null && !mGlobalLayoutListenerAddedFilter) {
treeObserver.addOnGlobalLayoutListener(this);
}
if (mAdapter != null && mDataSetObserver == null) {
mDataSetObserver = new AdapterDataSetObserver();
mAdapter.registerDataSetObserver(mDataSetObserver);
// Data may have changed while we were detached. Refresh.
mDataChanged = true;
mOldItemCount = mItemCount;
//通過getCount()獲取View元素的個數(shù)
mItemCount = mAdapter.getCount();
}
}
}
從上面我們可以看出吮旅，AbsListView是一個抽象類瘦棋，它里面封裝了一些固定的邏輯被廓，如Adapter模式的應(yīng)用邏輯党觅、布局的復(fù)用邏輯和布局子元素邏輯等。而具體的實現(xiàn)則是在子類ListView中倚喂。下面我們來看看ListView中是怎么處理每一個子元素View的每篷。
@Override
protected void layoutChildren() {
//省略其他代碼
case LAYOUT_FORCE_BOTTOM:
sel = fillUp(mItemCount - 1, childrenBottom);
adjustViewsUpOrDown();
break;
case LAYOUT_FORCE_TOP:
mFirstPosition = 0;
sel = fillFromTop(childrenTop);
adjustViewsUpOrDown();
break;
//省略其他代碼
}
在ListView中會覆寫AbsListView中的layoutChildren()函數(shù)，在layoutChildren()中會根據(jù)不同的情況進(jìn)行布局端圈，比如從上到下或者是從下往上雳攘。下面我們看看具體的布局方法fillUp方法。
private View fillUp(int pos, int nextBottom) {
//省略其他代碼
while (nextBottom > end && pos >= 0) {
// is this the selected item?
boolean selected = pos == mSelectedPosition;
View child = makeAndAddView(pos, nextBottom, false, mListPadding.left, selected);
nextBottom = child.getTop() - mDividerHeight;
if (selected) {
selectedView = child;
}
pos--;
}
mFirstPosition = pos + 1;
setVisibleRangeHint(mFirstPosition, mFirstPosition + getChildCount() - 1);
return selectedView;
}
這里我們看到fillUp方法里面又會通過makeAndAddView()方法來獲取View枫笛，下面我們來看看makeAndAddView()方法的實現(xiàn)
private View makeAndAddView(int position, int y, boolean flow, int childrenLeft,
boolean selected) {
if (!mDataChanged) {
// Try to use an existing view for this position.
final View activeView = mRecycler.getActiveView(position);
if (activeView != null) {
// Found it. We're reusing an existing child, so it just needs
// to be positioned like a scrap view.
setupChild(activeView, position, y, flow, childrenLeft, selected, true);
return activeView;
}
}
// Make a new view for this position, or convert an unused view if
// possible.
final View child = obtainView(position, mIsScrap);
// This needs to be positioned and measured.
setupChild(child, position, y, flow, childrenLeft, selected, mIsScrap[0]);
return child;
}
不知道大家看到這里想到了什么吨灭？
makeAndAddView()方法里面就出現(xiàn)了緩存機(jī)制了，這是提升ListView加載效率的關(guān)鍵方法刑巧。我們看到喧兄，在獲取子View時會先從緩存里面找，也就是會從mRecycler中找啊楚，mRecycler是AbsListView中的一個用于緩存的RecycleBin類吠冤，來，我們看看緩存的實現(xiàn)
class RecycleBin {
private View[] mActiveViews = new View[0];
/**
* Get the view corresponding to the specified position. The view will be removed from
* mActiveViews if it is found.
*
* @param position The position to look up in mActiveViews
* @return The view if it is found, null otherwise
*/
View getActiveView(int position) {
int index = position - mFirstActivePosition;
final View[] activeViews = mActiveViews;
if (index >=0 && index < activeViews.length) {
final View match = activeViews[index];
activeViews[index] = null;
return match;
}
return null;
}
}
由上可見恭理，緩存的View保存在一個View數(shù)組里面拯辙，然后我們來看看如果沒有找到緩存的View，ListView是怎么獲取子View的颜价，也就是上面的obtainView()方法涯保。需要注意的是obtainView()方法是在AbsListView里面。
View obtainView(int position, boolean[] outMetadata) {
//省略其他代碼
final View scrapView = mRecycler.getScrapView(position);
final View child = mAdapter.getView(position, scrapView, this);
if (scrapView != null) {
if (child != scrapView) {
// Failed to re-bind the data, return scrap to the heap.
mRecycler.addScrapView(scrapView, position);
} else if (child.isTemporarilyDetached()) {
outMetadata[0] = true;
// Finish the temporary detach started in addScrapView().
child.dispatchFinishTemporaryDetach();
}
}
//省略其他代碼
return child;
}
可以看到?jīng)]有緩存的View直接就是從我們編寫的Adapter的getView()方法里面獲取周伦。
以上我們簡單看了ListView中適配器模式的應(yīng)用夕春，從中我們可以看出ListView通過引入Adapter適配器類把那些多變的布局和數(shù)據(jù)交給用戶處理，然后通過適配器中的接口獲取需要的數(shù)據(jù)來完成自己的功能专挪，從而達(dá)到了很好的靈活性及志。這里面最重要的接口莫過于getView()接口了，該接口返回一個View對象寨腔，而千變?nèi)f化的UI視圖都是View的子類速侈，通過這樣一種處理就將子View的變化隔離了，保證了AbsListView類族的高度可定制化
總結(jié)
總結(jié)一下適配器模式的優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
- 將目標(biāo)類和適配者類解耦迫卢，通過引入一個適配器類來重用現(xiàn)有的適配者類倚搬，無需修改原有結(jié)構(gòu)。
- 增加了類的透明性和復(fù)用性靖避，將具體的業(yè)務(wù)實現(xiàn)過程封裝在適配者類中潭枣，對于客戶端類而言是透明的，而且提高了適配者的復(fù)用性幻捏，同一適配者類可以在多個不同的系統(tǒng)中復(fù)用盆犁。
- 靈活性和擴(kuò)展性都非常好，通過使用配置文件篡九，可以很方便的更換適配器谐岁，也可以在不修改原有代碼的基礎(chǔ)上 增加新的適配器，完全符合開閉原則榛臼。
缺點(diǎn)：
- 一次最多只能適配一個適配者類伊佃，不能同時適配多個適配者。
- 適配者類不能為最終類沛善，在C#中不能為sealed類
- 目標(biāo)抽象類只能為接口航揉，不能為類，其使用有一定的局限性金刁。
- 過多的使用適配器會讓系統(tǒng)顯得過于凌亂帅涂。如果不是很有必要，可以不適用適配器而是直接對系統(tǒng)進(jìn)行重構(gòu)
適用場景
- 系統(tǒng)需要使用現(xiàn)有的類尤蛮，而此類的接口不符合系統(tǒng)的需要媳友，即接口不兼容
- 想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類产捞，包括一些可能在將來引進(jìn)的一些類一起工作
- 需要一個統(tǒng)一的輸出接口醇锚，而輸入端的接口不可預(yù)知
