Android設(shè)計(jì)模式之適配器模式和應(yīng)用場(chǎng)景詳解
前言
設(shè)計(jì)模式有時(shí)候就是一道坎，但是設(shè)計(jì)模式又非常有用，過(guò)了這道坎，它可以讓你水平提高一個(gè)檔次。而在android開(kāi)發(fā)中，必要的了解一些設(shè)計(jì)模式又是必須的，因?yàn)樵O(shè)計(jì)模式在Android源碼中，可以說(shuō)是無(wú)處不在。
今天我們來(lái)講解適配器模式
一、適配器模式的定義和解決問(wèn)題
1、適配器模式把一個(gè)類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無(wú)法在一起工作的兩個(gè)類能夠在一起工作
2、是作為兩個(gè)不兼容的接口之間的橋梁。這種類型的設(shè)計(jì)模式屬于結(jié)構(gòu)型模式，它結(jié)合了兩個(gè)獨(dú)立接口的功能
3、將一個(gè)類的接口轉(zhuǎn)換成客戶希望的另外一個(gè)接口。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作
4、這種模式涉及到一個(gè)單一的類，該類負(fù)責(zé)加入獨(dú)立的或不兼容的接口功能。舉個(gè)真實(shí)的例子，讀卡器是作為內(nèi)存卡和筆記本之間的適配器。您將內(nèi)存卡插入讀卡器，再將讀卡器插入筆記本，這樣就可以通過(guò)筆記本來(lái)讀取內(nèi)存卡;
5、主要解決在軟件系統(tǒng)中，常常要將一些"現(xiàn)存的對(duì)象"放到新的環(huán)境中，而新環(huán)境要求的接口是現(xiàn)對(duì)象不能滿足的;
二、適用場(chǎng)景和優(yōu)缺點(diǎn)
1、使用場(chǎng)景
- 系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要，即接口不兼容;
- 想要建立一個(gè)可以重復(fù)使用的類，用于與一些彼此之間沒(méi)有太大關(guān)聯(lián)的一些類，包括一些可能在將來(lái)引進(jìn)的一些類一起工作;
- 需要一個(gè)統(tǒng)一的輸出接口，而輸入端的接口不可預(yù)知;
2、優(yōu)點(diǎn)
- 將目標(biāo)類和適配者類解耦，通過(guò)引入一個(gè)適配器類來(lái)重用現(xiàn)有的適配者類，無(wú)需修改原有結(jié)構(gòu)。
- 增加了類的透明性和復(fù)用性，將具體的業(yè)務(wù)實(shí)現(xiàn)過(guò)程封裝在適配者類中，對(duì)于客戶端類而言是透明的，而且提高了適配者的復(fù)用性，同一適配者類可以在多個(gè)不同的系統(tǒng)中復(fù)用。
- 靈活性和擴(kuò)展性都非常好，通過(guò)使用配置文件，可以很方便的更換適配器，也可以在不修改原有代碼的基礎(chǔ)上 增加新的適配器，完全符合開(kāi)閉原則。
3、缺點(diǎn)
- 過(guò)多地使用適配器，會(huì)讓系統(tǒng)非常零亂，不易整體進(jìn)行把握。比如，明明看到調(diào)用的是 A 接口，其實(shí)內(nèi)部被適配成了 B 接口的實(shí)現(xiàn)，一個(gè)系統(tǒng)如果太多出現(xiàn)這種情況，無(wú)異于一場(chǎng)災(zāi)難。因此如果不是很有必要，可以不使用適配器，而是直接對(duì)系統(tǒng)進(jìn)行重構(gòu)。
- 由于 JAVA 至多繼承一個(gè)類，所以至多只能適配一個(gè)適配者類，而且目標(biāo)類必須是抽象類。
- 一次最多只能適配一個(gè)適配者類，不能同時(shí)適配多個(gè)適配者。
- 目標(biāo)抽象類只能為接口，不能為類，其使用有一定的局限性;
三、適配器兩種模式
適配器模式有兩種：
- 類適配器
- 對(duì)象適配器
模式所涉及的角色有：
- 目標(biāo)(Target)角色：這就是所期待得到的接口。注意：由于這里討論的是類適配器模式，因此目標(biāo)不可以是類。
- 源(Adapee)角色：現(xiàn)在需要適配的接口。
- 適配器(Adaper)角色：適配器類是本模式的核心。適配器把源接口轉(zhuǎn)換成目標(biāo)接口。顯然，這一角色不可以是接口，而必須是具體類。
場(chǎng)景：
假如A類想用M方法，X類有M方法，但是M方法的結(jié)果不一定完全符合A類的需求
那么X類就是寫(xiě)死了，不好用，這樣設(shè)計(jì)不好
那就把X類換成一個(gè)接口，弄出一些B，C，D，E.....類中間類出來(lái)，讓他們都有一個(gè)方法來(lái)處理M方法的東西，再給A類用
1、類適配器：
設(shè)計(jì)一個(gè)接口I，讓他也有M方法
然后設(shè)計(jì)一個(gè)B類，寫(xiě)好符合A類需求的specialM方法
然后讓A類繼承B類，并實(shí)現(xiàn)I接口的M方法
最后在A類的M方法中以super的方式調(diào)用B類的specialM方法
2、對(duì)象適配器：(更多是用對(duì)象適配器)
設(shè)計(jì)一個(gè)接口I，讓他也有M方法
然后設(shè)計(jì)一個(gè)B類，寫(xiě)好符合A類需求的specialM方法
然后在A類中聲明一個(gè)B類變量，并且A類實(shí)現(xiàn)I接口，那么A類也就有了M方法
最后在A類的M方法中，如果需要，就可以選擇調(diào)用B類的specialM方法
或者設(shè)計(jì)一個(gè)B類，實(shí)現(xiàn)I接口的M方法
然后在A類中聲明一個(gè)I類變量，再直接調(diào)用I接口的M方法
在調(diào)用A類的M方法之前，通過(guò)例如setAdapter(I Adapter)這樣的方法，將B類設(shè)置成A類的成員變量
這樣就保證了A類和I接口不變，適配不同情況的時(shí)候，寫(xiě)一個(gè)類似B類的中間類進(jìn)行適配就可以了
總之，兩端不變，通過(guò)不同的選擇方式，選擇不同的中間類，也就是適配器模式了
三、現(xiàn)實(shí)中適配器案例
實(shí)現(xiàn)
這里我們通過(guò)一個(gè)實(shí)例來(lái)模擬一下適配器模式。需求是這樣的：IPhone12的耳機(jī)口被取消，我們?cè)趺幢ＷC之前的耳機(jī)還能用呢?當(dāng)然是需要一個(gè)轉(zhuǎn)接頭了，這個(gè)轉(zhuǎn)接頭呢，其實(shí)就類似我們的適配器。
耳機(jī)需要的接口就是我們的目標(biāo)角色，手機(jī)提供的接口就是我們的源角色，轉(zhuǎn)接頭當(dāng)然就是適配器角色了。
類適配器
目標(biāo)角色
- 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);
- }
- /**
- * 轉(zhuǎn)換操作
- * @param newInterface
- * @return
- */
- private String suit(String newInterface) {
- return "3.5mm interface";
- }
- }
對(duì)象適配器
對(duì)象適配器的目標(biāo)角色和源角色是一樣的，我們就不再寫(xiě)了。
適配器
- 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);
- }
- /**
- * 轉(zhuǎn)換操作
- * @param newInterface
- * @return
- */
- private String suit(String newInterface) {
- return "3.5mm interface";
- }
- }
四、Android中的應(yīng)用場(chǎng)景
適配器模式在android中的應(yīng)用非常廣，最常見(jiàn)的ListView、GridView、RecyclerView等的Adapter。而，我們經(jīng)常使用的ListView就是一個(gè)典范。
在使用ListView時(shí)，每一項(xiàng)的布局和數(shù)據(jù)都不一樣，但是最后輸出都可以看作是一個(gè)View，這就對(duì)應(yīng)了上面的適配器模式應(yīng)用場(chǎng)景的第三條：需要一個(gè)統(tǒng)一的輸出接口，而輸入端的接口不可預(yù)知。下面我們來(lái)看看ListView中的適配器模式。
首先我們來(lái)看看一般我們的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則通過(guò)這些接口來(lái)執(zhí)行具體的布局、緩存等工作。下面我們來(lái)簡(jiǎn)單看看ListView的實(shí)現(xiàn)。
首先這些getCount()等接口都在一個(gè)接口類Adapter里
- public interface Adapter {
- //省略其他的接口
- int getCount();
- Object getItem(int position);
- long getItemId(int position);
- View getView(int position, View convertView, ViewGroup parent);
- //省略其他的接口
- }
- 中間加了一個(gè)過(guò)渡的接口ListAdapter
- public interface ListAdapter extends Adapter {
- //接口省略
- }
我們?cè)诰帉?xiě)我們自己的Adapter時(shí)都會(huì)繼承一個(gè)BaseAdapter，我們來(lái)看看BaseAdapter
- public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter {
- //BaseAdapter里面實(shí)現(xiàn)了ListAdapter的接口以及部分Adapter中的接口
- //而像getCount()以及getView()這些接口則需要我們自己去實(shí)現(xiàn)
- }
- ListView的父類AbsListView中有ListAdapter接口，通過(guò)這個(gè)接口來(lái)調(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;
- //通過(guò)getCount()獲取View元素的個(gè)數(shù)
- mItemCount = mAdapter.getCount();
- }
- }
- }
從上面我們可以看出，AbsListView是一個(gè)抽象類，它里面封裝了一些固定的邏輯，如Adapter模式的應(yīng)用邏輯、布局的復(fù)用邏輯和布局子元素邏輯等。而具體的實(shí)現(xiàn)則是在子類ListView中。下面我們來(lái)看看ListView中是怎么處理每一個(gè)子元素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中會(huì)覆寫(xiě)AbsListView中的layoutChildren()函數(shù)，在layoutChildren()中會(huì)根據(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方法里面又會(huì)通過(guò)makeAndAddView()方法來(lái)獲取View，下面我們來(lái)看看makeAndAddView()方法的實(shí)現(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時(shí)會(huì)先從緩存里面找，也就是會(huì)從mRecycler中找，mRecycler是AbsListView中的一個(gè)用于緩存的RecycleBin類，來(lái)，我們看看緩存的實(shí)現(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;
- }
- }
由上可見(jiàn)，緩存的View保存在一個(gè)View數(shù)組里面，然后我們來(lái)看看如果沒(méi)有找到緩存的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直接就是從我們編寫(xiě)的Adapter的getView()方法里面獲取。
以上我們簡(jiǎn)單看了ListView中適配器模式的應(yīng)用，從中我們可以看出ListView通過(guò)引入Adapter適配器類把那些多變的布局和數(shù)據(jù)交給用戶處理，然后通過(guò)適配器中的接口獲取需要的數(shù)據(jù)來(lái)完成自己的功能，從而達(dá)到了很好的靈活性。這里面最重要的接口莫過(guò)于getView()接口了，該接口返回一個(gè)View對(duì)象，而千變?nèi)f化的UI視圖都是View的子類，通過(guò)這樣一種處理就將子View的變化隔離了，保證了AbsListView類族的高度可定制化。
總結(jié)：
- 更好的復(fù)用性：系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要。那么通過(guò)適配器模式就可以讓這些功能得到更好的復(fù)用。
- 更好的擴(kuò)展性：在實(shí)現(xiàn)適配器功能的時(shí)候，可以調(diào)用自己開(kāi)發(fā)的功能，從而自然地?cái)U(kuò)展系統(tǒng)的功能。
本文轉(zhuǎn)載自微信公眾號(hào)「 Android開(kāi)發(fā)編程」
