Android ListView 介面卡模式解析

Mr.Simple的專欄發表於2015-04-05
AndroidView模式

模式的定義

介面卡模式把一個類的介面變換成客戶端所期待的另一種介面，從而使原本因介面不匹配而無法在一起工作的兩個類能夠在一起工作。

使用場景

用電源介面做例子，膝上型電腦的電源一般都是接受5V的電壓，但是我們生活中的電線電壓一般都是220V的輸出。這個時候就出現了不匹配的狀況，在軟體開發中我們稱之為介面不相容，此時就需要介面卡來進行一個介面轉換。在軟體開發中有一句話正好體現了這點：任何問題都可以加一箇中間層來解決。這個層我們可以理解為這裡的Adapter層，通過這層來進行一個介面轉換就達到了相容的目的。

介面卡模式也分兩種，即類介面卡模式、物件介面卡模式，結構圖如圖1、圖2。

圖1 圖2

如圖所示，類介面卡是通過實現Target介面以及繼承Adaptee類來實現介面轉換，而物件介面卡模式則是通過實現Target介面和代理Adaptee的某個方法來實現。結構上略有不同。

角色介紹

  • 目標(Target)角色：這就是所期待得到的介面。注意：由於這裡討論的是類介面卡模式，因此目標不可以是類。
  • 源(Adapee)角色：現在需要適配的介面。
  • 介面卡(Adaper)角色：介面卡類是本模式的核心。介面卡把源介面轉換成目標介面。顯然，這一角色不可以是介面，而必須是具體類。在上述電源介面這個示例中，5V電壓就是Target介面，220v電壓就是Adaptee類，而將電壓從220V轉換到5V就是Adapter。

具體示例

類介面卡模式

/**
 * Target角色
 */
public interface FiveVolt {
    public int getVolt5();
}

/**
 * Adaptee角色,需要被轉換的物件
 */
public class Volt220 {
    public int getVolt220() {
        return 220;
    }
}

// adapter角色
public class ClassAdapter extends Volt220 implements FiveVolt {

    @Override
    public int getVolt5() {
        return 5;
    }

}

Target角色給出了需要的目標介面，而Adaptee類則是需要被轉換的物件。Adapter則是將Volt220轉換成Target的介面。對應的是Target的目標是要獲取5V的輸出電壓，而Adaptee即正常輸出電壓是220V，此時我們就需要電源介面卡類將220V的電壓轉換為5V電壓，解決介面不相容的問題。

public class Test {
    public static void main(String[] args) {
        ClassAdapter adapter = new ClassAdapter();
        System.out.println("輸出電壓 : " + adapter.getVolt5());
    }
}

物件介面卡模式

與類的介面卡模式一樣，物件的介面卡模式把被適配的類的API轉換成為目標類的API，與類的介面卡模式不同的是，物件的介面卡模式不是使用繼承關係連線到Adaptee類，而是使用代理關係連線到Adaptee類。

從圖2可以看出，Adaptee類 ( Volt220 ) 並沒有getVolt5()方法，而客戶端則期待這個方法。為使客戶端能夠使用Adaptee類，需要提供一個包裝類Adapter。這個包裝類包裝了一個Adaptee的例項，從而此包裝類能夠把Adaptee的API與Target類的API銜接起來。Adapter與Adaptee是委派關係，這決定了介面卡模式是物件的。

示例程式碼如下 :

/**
 * Target角色
 */
public interface FiveVolt {
    public int getVolt5();
}

/**
 * Adaptee角色,需要被轉換的物件
 */
public class Volt220 {
    public int getVolt220() {
        return 220;
    }
}

// 物件介面卡模式
public class ObjectAdapter implements FiveVolt {

    Volt220 mVolt220;

    public ObjectAdapter(Volt220 adaptee) {
        mVolt220 = adaptee;
    }

    public int getVolt220() {
        return mVolt220.getVolt220();
    }

    @Override
    public int getVolt5() {
        return 5;
    }

}

注意，這裡為了節省程式碼，我們並沒有遵循一些物件導向的基本原則。

使用示例 :

public class Test {
    public static void main(String[] args) {
        ClassAdapter adapter = new ClassAdapter();
        System.out.println("輸出電壓 : " + adapter.getVolt5());
    }
}

類介面卡和物件介面卡的權衡

*　　類介面卡使用物件繼承的方式，是靜態的定義方式；而物件介面卡使用物件組合的方式，是動態組合的方式。

*　　對於類介面卡，由於介面卡直接繼承了Adaptee，使得介面卡不能和Adaptee的子類一起工作，因為繼承是靜態的關係，當介面卡繼承了Adaptee後，就不可能再去處理Adaptee的子類了。對於物件介面卡，一個介面卡可以把多種不同的源適配到同一個目標。換言之，同一個介面卡可以把源類和它的子類都適配到目標介面。因為物件介面卡採用的是物件組合的關係，只要物件型別正確，是不是子類都無所謂。

*　 對於類介面卡，介面卡可以重定義Adaptee的部分行為，相當於子類覆蓋父類的部分實現方法。對於物件介面卡，要重定義Adaptee的行為比較困難，這種情況下，需要定義Adaptee的子類來實現重定義，然後讓介面卡組合子類。雖然重定義Adaptee的行為比較困難，但是想要增加一些新的行為則方便的很，而且新增加的行為可同時適用於所有的源。

*　　對於類介面卡，僅僅引入了一個物件，並不需要額外的引用來間接得到Adaptee。對於物件介面卡，需要額外的引用來間接得到Adaptee。

建議儘量使用物件介面卡的實現方式，多用合成/聚合、少用繼承。當然，具體問題具體分析，根據需要來選用實現方式，最適合的才是最好的。

ListView中的Adapter模式

在開發過程中,ListView的Adapter是我們最為常見的型別之一。一般的用法大致如下:

// 程式碼省略
 ListView myListView = (ListView)findViewById(listview_id);
 // 設定介面卡
 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;
        }

        // 解析、設定、快取convertView以及相關內容
        @Override
        public View getView(int position, View convertView, ViewGroup parent) { 
            ViewHolder holder = null;
            // Item View的複用
            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;
        }

    }

這看起來似乎還挺麻煩的，看到這裡我們不禁要問，ListView為什麼要使用Adapter模式呢？
我們知道，作為最重要的View，ListView需要能夠顯示各式各樣的檢視，每個人需要的顯示效果各不相同，顯示的資料型別、數量等也千變萬化。那麼如何隔離這種變化尤為重要。

Android的做法是增加一個Adapter層來應對變化，將ListView需要的介面抽象到Adapter物件中，這樣只要使用者實現了Adapter的介面，ListView就可以按照使用者設定的顯示效果、數量、資料來顯示特定的Item View。
通過代理資料集來告知ListView資料的個數( getCount函式 )以及每個資料的型別( getItem函式 )，最重要的是要解決Item View的輸出。Item View千變萬化，但終究它都是View型別，Adapter統一將Item View輸出為View ( getView函式 )，這樣就很好的應對了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 ;

    // 關聯到Window時呼叫的函式
    @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的數量,呼叫的是mAdapter的getCount方法
            mItemCount = mAdapter.getCount();
        }
        mIsAttached = true;
    }

  /**
     * 子類需要覆寫layoutChildren()函式來佈局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的複用機制就在這裡
        scrapView = mRecycler.getScrapView(position);

        View child;
        if (scrapView != null) {
            // 程式碼省略
            child = mAdapter.getView(position, scrapView, this);
            // 程式碼省略
        } else {
            child = mAdapter.getView(position, null, this);
            // 程式碼省略
        }

        return child;
    }
    }

AbsListView定義了集合檢視的框架，比如Adapter模式的應用、複用Item View的邏輯、佈局Item View的邏輯等。子類只需要覆寫特定的方法即可實現集合檢視的功能，例如ListView。

ListView中的相關方法。

    @Override
    protected void layoutChildren() {
        // 程式碼省略

        try {
            super.layoutChildren();
            invalidate();
            // 程式碼省略
            // 根據佈局模式來佈局Item View
            switch (mLayoutMode) {
            case LAYOUT_SET_SELECTION:
                if (newSel != null) {
                    sel = fillFromSelection(newSel.getTop(), childrenTop, childrenBottom);
                } else {
                    sel = fillFromMiddle(childrenTop, childrenBottom);
                }
                break;
            case LAYOUT_SYNC:
                sel = fillSpecific(mSyncPosition, mSpecificTop);
                break;
            case LAYOUT_FORCE_BOTTOM:
                sel = fillUp(mItemCount - 1, childrenBottom);
                adjustViewsUpOrDown();
                break;
            case LAYOUT_FORCE_TOP:
                mFirstPosition = 0;
                sel = fillFromTop(childrenTop);
                adjustViewsUpOrDown();
                break;
            case LAYOUT_SPECIFIC:
                sel = fillSpecific(reconcileSelectedPosition(), mSpecificTop);
                break;
            case LAYOUT_MOVE_SELECTION:
                sel = moveSelection(oldSel, newSel, delta, childrenTop, childrenBottom);
                break;
            default:
                // 程式碼省略
                break;
            }

    }

    // 從上到下填充Item View  [ 只是其中一種填充方式 ]
    private View fillDown(int pos, int nextTop) {
        View selectedView = null;

        int end = (mBottom - mTop);
        if ((mGroupFlags & CLIP_TO_PADDING_MASK) == CLIP_TO_PADDING_MASK) {
            end -= mListPadding.bottom;
        }

        while (nextTop < end && pos < mItemCount) {
            // is this the selected item?
            boolean selected = pos == mSelectedPosition;
            View child = makeAndAddView(pos, nextTop, true, mListPadding.left, selected);

            nextTop = child.getBottom() + mDividerHeight;
            if (selected) {
                selectedView = child;
            }
            pos++;
        }

        return selectedView;
    }

    // 新增Item View
    private View makeAndAddView(int position, int y, boolean flow, int childrenLeft,
            boolean selected) {
        View child;

        // 程式碼省略 
        // Make a new view for this position, or convert an unused view if possible
        child = obtainView(position, mIsScrap);

        // This needs to be positioned and measured
        setupChild(child, position, y, flow, childrenLeft, selected, mIsScrap[0]);

        return child;
    }

ListView覆寫了AbsListView中的layoutChilden函式，在該函式中根據佈局模式來佈局Item View。Item View的個數、樣式都通過Adapter對應的方法來獲取，獲取個數、Item View之後，將這些Item View佈局到ListView對應的座標上，再加上Item View的複用機制，整個ListView就基本運轉起來了。

當然這裡的Adapter並不是經典的介面卡模式，但是卻是物件介面卡模式的優秀示例，也很好的體現了物件導向的一些基本原則。這裡的Target角色和Adapter角色融合在一起，Adapter中的方法就是目標方法；而Adaptee角色就是ListView的資料集與Item View，Adapter代理資料集，從而獲取到資料集的個數、元素。

通過增加Adapter一層來將Item View的操作抽象起來，ListView等集合檢視通過Adapter物件獲得Item的個數、資料元素、Item View等，從而達到適配各種資料、各種Item檢視的效果。因為Item View和資料型別千變萬化，Android的架構師們將這些變化的部分交給使用者來處理，通過getCount、getItem、getView等幾個方法抽象出來，也就是將Item View的構造過程交給使用者來處理，靈活地運用了介面卡模式，達到了無限適配、擁抱變化的目的。

介面卡模式的優點

*　更好的複用性
系統需要使用現有的類，而此類的介面不符合系統的需要。那麼通過介面卡模式就可以讓這些功能得到更好的複用。

*　更好的擴充套件性
在實現介面卡功能的時候，可以呼叫自己開發的功能，從而自然地擴充套件系統的功能。

介面卡模式的缺點

過多的使用介面卡，會讓系統非常零亂，不易整體進行把握。比如，明明看到呼叫的是A介面，其實內部被適配成了B介面的實現，一個系統如果太多出現這種情況，無異於一場災難。因此如果不是很有必要，可以不使用介面卡，而是直接對系統進行重構。

相關文章