[[417879]]

前言

設計模式有時候就是一道坎，但是設計模式又非常有用，過了這道坎，它可以讓你水平提高一個檔次。而在android開發中，必要的了解一些設計模式又是必須的，因為設計模式在Android源碼中，可以說是無處不在。

今天我們來講解適配器模式

一、適配器模式的定義和解決問題

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

2、是作為兩個不兼容的接口之間的橋梁。這種類型的設計模式屬于結構型模式，它結合了兩個獨立接口的功能

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

4、這種模式涉及到一個單一的類，該類負責加入獨立的或不兼容的接口功能。舉個真實的例子，讀卡器是作為內存卡和筆記本之間的適配器。您將內存卡插入讀卡器，再將讀卡器插入筆記本，這樣就可以通過筆記本來讀取內存卡;

5、主要解決在軟件系統中，常常要將一些"現存的對象"放到新的環境中，而新環境要求的接口是現對象不能滿足的;

二、適用場景和優缺點

1、使用場景

• 系統需要使用現有的類，而此類的接口不符合系統的需要，即接口不兼容;
• 想要建立一個可以重復使用的類，用于與一些彼此之間沒有太大關聯的一些類，包括一些可能在將來引進的一些類一起工作;
• 需要一個統一的輸出接口，而輸入端的接口不可預知;

2、優點

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

3、缺點

• 過多地使用適配器，會讓系統非常零亂，不易整體進行把握。比如，明明看到調用的是 A 接口，其實內部被適配成了 B 接口的實現，一個系統如果太多出現這種情況，無異于一場災難。因此如果不是很有必要，可以不使用適配器，而是直接對系統進行重構。
• 由于 JAVA 至多繼承一個類，所以至多只能適配一個適配者類，而且目標類必須是抽象類。
• 一次最多只能適配一個適配者類，不能同時適配多個適配者。
• 目標抽象類只能為接口，不能為類，其使用有一定的局限性;

三、適配器兩種模式

適配器模式有兩種：

• 類適配器
• 對象適配器

模式所涉及的角色有：

• 目標(Target)角色：這就是所期待得到的接口。注意：由于這里討論的是類適配器模式，因此目標不可以是類。
• 源(Adapee)角色：現在需要適配的接口。
• 適配器(Adaper)角色：適配器類是本模式的核心。適配器把源接口轉換成目標接口。顯然，這一角色不可以是接口，而必須是具體類。

場景：

假如A類想用M方法，X類有M方法，但是M方法的結果不一定完全符合A類的需求

那么X類就是寫死了，不好用，這樣設計不好

那就把X類換成一個接口，弄出一些B，C，D，E.....類中間類出來，讓他們都有一個方法來處理M方法的東西，再給A類用

1、類適配器：

設計一個接口I，讓他也有M方法

然后設計一個B類，寫好符合A類需求的specialM方法

然后讓A類繼承B類，并實現I接口的M方法

最后在A類的M方法中以super的方式調用B類的specialM方法

2、對象適配器：(更多是用對象適配器)

設計一個接口I，讓他也有M方法

然后設計一個B類，寫好符合A類需求的specialM方法

然后在A類中聲明一個B類變量，并且A類實現I接口，那么A類也就有了M方法

最后在A類的M方法中，如果需要，就可以選擇調用B類的specialM方法

或者設計一個B類，實現I接口的M方法

然后在A類中聲明一個I類變量，再直接調用I接口的M方法

在調用A類的M方法之前，通過例如setAdapter(I Adapter)這樣的方法，將B類設置成A類的成員變量

這樣就保證了A類和I接口不變，適配不同情況的時候，寫一個類似B類的中間類進行適配就可以了

總之，兩端不變，通過不同的選擇方式，選擇不同的中間類，也就是適配器模式了

三、現實中適配器案例

實現

這里我們通過一個實例來模擬一下適配器模式。需求是這樣的：IPhone12的耳機口被取消，我們怎么保證之前的耳機還能用呢?當然是需要一個轉接頭了，這個轉接頭呢，其實就類似我們的適配器。

耳機需要的接口就是我們的目標角色，手機提供的接口就是我們的源角色，轉接頭當然就是適配器角色了。

類適配器

目標角色

public interface ITarget { 
    //獲取需要的接口 
    String getRightInterface(); 
} 

源角色

public class IPhoneSeven { 
    //獲取iphone7提供的接口 
    public String getInterface(){ 
        return "iphone7 interface"; 
    } 
} 

適配器

public class CAdapter extends IPhoneSeven implements ITarget{ 
    @Override 
    public String getRightInterface() { 
        String newInterface = getInterface(); 
        return suit(newInterface); 
    } 
    /** 
     * 轉換操作 
     * @param newInterface 
     * @return 
     */ 
    private String suit(String newInterface) { 
        return "3.5mm interface"; 
    } 
} 

對象適配器

對象適配器的目標角色和源角色是一樣的，我們就不再寫了。

適配器

public class Adapter implements ITarget { 
    private IPhoneSeven mIPhoneSeven; 
    public Adapter(IPhoneSeven IPhoneSeven) { 
        mIPhoneSeven = IPhoneSeven; 
    } 
    @Override 
    public String getRightInterface() { 
        String newInterface = mIPhoneSeven.getInterface(); 
        return suit(newInterface); 
    } 
    /** 
     * 轉換操作 
     * @param newInterface 
     * @return 
     */ 
    private String suit(String newInterface) { 
        return "3.5mm interface"; 
    } 
} 

四、Android中的應用場景

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

在使用ListView時，每一項的布局和數據都不一樣，但是最后輸出都可以看作是一個View，這就對應了上面的適配器模式應用場景的第三條：需要一個統一的輸出接口，而輸入端的接口不可預知。下面我們來看看ListView中的適配器模式。

首先我們來看看一般我們的Adapter類的結構

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 
        } 
        //初始化數據 
        return convertView; 
    } 
} 

可以看出Adapter里面的接口主要是getCount()返回子View的數量，以及getView()返回我們填充好數據的View，ListView則通過這些接口來執行具體的布局、緩存等工作。下面我們來簡單看看ListView的實現。

首先這些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里面實現了ListAdapter的接口以及部分Adapter中的接口 
    //而像getCount()以及getView()這些接口則需要我們自己去實現 
} 
ListView的父類AbsListView中有ListAdapter接口，通過這個接口來調用getCount()等方法獲取View的數量等 
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元素的個數 
            mItemCount = mAdapter.getCount(); 
        } 
    } 
} 

從上面我們可以看出，AbsListView是一個抽象類，它里面封裝了一些固定的邏輯，如Adapter模式的應用邏輯、布局的復用邏輯和布局子元素邏輯等。而具體的實現則是在子類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()函數，在layoutChildren()中會根據不同的情況進行布局，比如從上到下或者是從下往上。下面我們看看具體的布局方法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()方法的實現。

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()方法里面就出現了緩存機制了，這是提升ListView加載效率的關鍵方法。我們看到，在獲取子View時會先從緩存里面找，也就是會從mRecycler中找，mRecycler是AbsListView中的一個用于緩存的RecycleBin類，來，我們看看緩存的實現。

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數組里面，然后我們來看看如果沒有找到緩存的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; 
} 

可以看到沒有緩存的View直接就是從我們編寫的Adapter的getView()方法里面獲取。

以上我們簡單看了ListView中適配器模式的應用，從中我們可以看出ListView通過引入Adapter適配器類把那些多變的布局和數據交給用戶處理，然后通過適配器中的接口獲取需要的數據來完成自己的功能，從而達到了很好的靈活性。這里面最重要的接口莫過于getView()接口了，該接口返回一個View對象，而千變萬化的UI視圖都是View的子類，通過這樣一種處理就將子View的變化隔離了，保證了AbsListView類族的高度可定制化。

[[417880]]

總結：

• 更好的復用性：系統需要使用現有的類，而此類的接口不符合系統的需要。那么通過適配器模式就可以讓這些功能得到更好的復用。
• 更好的擴展性：在實現適配器功能的時候，可以調用自己開發的功能，從而自然地擴展系統的功能。

本文轉載自微信公眾號「 Android開發編程」