Android常見設計模式五：適配器模式

對于開發(fā)人員來說，設計模式有時候就是一道坎，但是設計模式又非常有用，過了這道坎，它可以讓你水平提高一個檔次。而在android開發(fā)中，必要的了解一些設計模式又是必須的，因為設計模式在Android源碼中，可以說是無處不在。對于想系統(tǒng)的學習設計模式的同學，這里推薦一本書，《大話設計模式》。

Android常用設計模式系列：

面向?qū)ο蟮幕A(chǔ)特征
面向?qū)ο蟮脑O計原則
單例模式
模板模式
適配器模式
工廠模式
代理模式
原型模式
策略模式
Build模式
觀察者模式
裝飾者模式
中介模式
門面模式

適配器模式

適配器模式是非常常見的設計模式之一，寫個筆記，記錄一下我的學習過程和心得。

首先了解一些適配器模式的定義。

將一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作。

齋看定義，也是有點難理解的，還是要結(jié)合一個列子來進行講，有助于我們更好的理解。

生活中的手機充電器就是一個適配器的例子，手機一般都是在5V的電壓下進行充電，但是外部的電壓都是220V，那怎么辦，這就需要充電器去適配了，將220V的電壓轉(zhuǎn)換為5V。

根據(jù)適配器模式的定義，我們知道有三個角色參與了其中的工作：

  • Adapter(適配器接口):即目標角色，定義把其他類轉(zhuǎn)換為何種接口，也就是我們期望的接口。
  • Adaptee(被適配角色):即源角色，一般是已存在的類，需要適配新的接口。
  • ConcreteAdapter(具體適配器):實現(xiàn)適配器接口，把源角色接口轉(zhuǎn)換為目標角色期望的接口。

那么，我們就開始實現(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 {//手機適配器類
        private Electric mElectric;//適配器持有源目標對象

        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("默認電壓：" + electric.output_220v());

    Adapter phoneAdapter = new PhoneAdapter(electric);//傳遞一個對象給適配器
    System.out.println("適配轉(zhuǎn)換后的電壓：" + phoneAdapter.convert_5v());

}

輸出結(jié)果：

默認電壓：220
適配器開始工作：
輸入電壓：220
輸出電壓：5
適配轉(zhuǎn)換后的電壓：5

OK，這樣就完成了一個適配器模式的實現(xiàn)。
這里實現(xiàn)的例子只是適配器模式其中的一種，其實適配器模式分為

對象適配器模式
類適配器模式

這里我們講的是對象適配器的實現(xiàn)，類適配器的原理差不多的，只是類適配器模式?jīng)]什么優(yōu)勢，用得比較少，這里就不做詳細講解了。

接下來把他們做一下對比：

  • 類適配器采用了繼承的方式來實現(xiàn);而對象適配器是通過傳遞對象來實現(xiàn)，這是一種組合的方式。
  • 類適配器由于采用了繼承，可以重寫父類的方法;對象適配器則不能修改對象本身的方法等。
  • 適配器通過繼承都獲得了父類的方法，客戶端使用時都會把這些方法暴露出去，增加了一定的使用成本;對象適配器則不會。
  • 類適配器只能適配他的父類，這個父類的其他子類都不能適配到;而對象適配器可以適配不同的對象，只要這個對象的類型是同樣的。
  • 類適配器不需要額外的引用;對象適配器需要額外的引用來保存對象。

廣泛應用

適配器模式在android中的應用非常廣，最常見的ListView、GridView、RecyclerView等的Adapter。而，我們經(jīng)常使用的ListView就是一個典范。

在使用ListView時，每一項的布局和數(shù)據(jù)都不一樣，但是最后輸出都可以看作是一個View，這就對應了上面的適配器模式應用場景的第三條：需要一個統(tǒng)一的輸出接口，而輸入端的接口不可預知。下面我們來看看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模式的應用邏輯、布局的復用邏輯和布局子元素邏輯等。而具體的實現(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ù)不同的情況進行布局，比如從上到下或者是從下往上。下面我們看看具體的布局方法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)了緩存機制了，這是提升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中適配器模式的應用，從中我們可以看出ListView通過引入Adapter適配器類把那些多變的布局和數(shù)據(jù)交給用戶處理，然后通過適配器中的接口獲取需要的數(shù)據(jù)來完成自己的功能，從而達到了很好的靈活性。這里面最重要的接口莫過于getView()接口了，該接口返回一個View對象，而千變?nèi)f化的UI視圖都是View的子類，通過這樣一種處理就將子View的變化隔離了，保證了AbsListView類族的高度可定制化

總結(jié)

總結(jié)一下適配器模式的優(yōu)缺點

優(yōu)點：

  1. 將目標類和適配者類解耦，通過引入一個適配器類來重用現(xiàn)有的適配者類，無需修改原有結(jié)構(gòu)。
  2. 增加了類的透明性和復用性，將具體的業(yè)務實現(xiàn)過程封裝在適配者類中，對于客戶端類而言是透明的，而且提高了適配者的復用性，同一適配者類可以在多個不同的系統(tǒng)中復用。
  3. 靈活性和擴展性都非常好，通過使用配置文件，可以很方便的更換適配器，也可以在不修改原有代碼的基礎(chǔ)上 增加新的適配器，完全符合開閉原則。

缺點：

  1. 一次最多只能適配一個適配者類，不能同時適配多個適配者。
  2. 適配者類不能為最終類，在C#中不能為sealed類
  3. 目標抽象類只能為接口，不能為類，其使用有一定的局限性。
  4. 過多的使用適配器會讓系統(tǒng)顯得過于凌亂。如果不是很有必要，可以不適用適配器而是直接對系統(tǒng)進行重構(gòu)

適用場景

  1. 系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要，即接口不兼容
  2. 想要建立一個可以重復使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進的一些類一起工作
  3. 需要一個統(tǒng)一的輸出接口，而輸入端的接口不可預知
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

推薦閱讀更多精彩內(nèi)容