Android设计模式之适配器模式和应用场景详解-android 适配器模式

[[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类族的高度可定制化。

总结：

更好的复用性：系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。
更好的扩展性：在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。

本文转载自微信公众号「 Android开发编程」