这篇来介绍一下适配器模式（Adapter Pattern），适配器模式在开发中使用的频率也是很高的，像 ListView 和 RecyclerView 的 Adapter 等都是使用的适配器模式。在我们的实际生活中也有很多类似于适配器的例子，比如香港的插座和大陆的插座就是两种格式的，为了能够成功适配，一般会在中间加上一个电源适配器，形如：

è¿éåå¾çæè¿°

这样就能够将原来不符合的现有系统和目标系统通过适配器成功连接。

　　说到底，适配器模式是将原来不兼容的两个类融合在一起，它有点类似于粘合剂，将不同的东西通过一种转换使得它们能够协作起来。碰到要在两个完全没有关系的类之间进行交互，第一个解决方案是修改各自类的接口，但是如果无法修改源代码或者其他原因导致无法更改接口，此时怎么办？这种情况我们往往会使用一个 Adapter ，在这两个接口之间创建一个粘合剂接口，将原本无法协作的类进行兼容，而且不用修改原来两个模块的代码，符合开闭原则。

设计模式总目录

　　java/android 设计模式学习笔记目录

特点

　　适配器模式把一个类的接口换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

　　所以，这个模式可以通过创建适配器进行接口转换，让不兼容的接口兼容，这可以让客户实现解耦。如果在一段时间之后，我们想要改变接口，适配器可以将改变的部分封装起来，客户就不必为了应对不同的接口而每次跟着修改。
　　适配器模式的使用场景可以有以下几种：

系统需要使用现有的类，而此类的接口不符合系统的需要，即接口不兼容；
想要建立一个可以重复使用的类，用于与一些彼此之间没有太大联系的一些类，包括一些可能在将来引进的类一起工作；
需要一个统一的输出接口，而输入端的类型不可预知。

UML类图

　　适配器模式在实际使用过程中有“两种”方式：对象适配器和类适配器。

类适配器模式

首先看一下类适配器模式的 uml 类图：

è¿éåå¾çæè¿°

类适配器是通过实现 ITarget 接口以及继承 Adaptee 类来实现接口转换，目标接口需要的是 operation1() 的操作，而 Adaptee 类只能提供一个 operation2() 的操作，因此就出现了不兼容的情况，此时通过 Adapter 实现一个 operation1() 函数将 Adaptee 的 operation2() 转换为 ITarget 需要的操作，以此实现兼容。类适配器模式有三个角色：

Target：目标角色，也就是所期待得到的接口，由于这里讨论的是类适配器模式，因此目标不可以是类；
Adaptee：现在需要适配的接口；
Adapter：适配器角色，适配器把源接口转换成目标接口，所以这一个角色必须是具体类。

对象适配器模式

对象适配器模式 uml 类图：

è¿éåå¾çæè¿°

uml 类图和类适配器模式基本一样，区别就在于对象适配器模式与 Adaptee 的关系是 Dependency，而类适配器是 Generalization ，一个是依赖，一个是继承。所以 Adapter 类会持有一个 Adaptee 对象的引用，并且通过 operation1() 方法将该 Adaptee 对象与 ITarget 接口的相关操作衔接起来。
　　这种实现方式直接将要被适配的对象传递到 Adapter 中，使用组合的形式实现接口兼容的效果，这种模式比类适配器模式更加灵活，它的另一个好处是被适配对象中的方法不会暴露出来，而类适配器由于继承了被适配对象，因此，被适配对象类的函数在 Adapter 类中也都含有，这使得 Adapter 类出现了一些奇怪的接口，用于使用成本较高。因此，对象适配器模式更加灵活和实用。

对比

　　类适配器模式使用的是继承的方式，而对象适配器模式则使用的是组合的方法。从设计模式的角度来说，对象适配器模式遵循 OO 设计原则的“多用组合，少用继承”，这是一个优点，但是类适配器模式有一个好处是它不需要重新实现整个被适配者的行为，毕竟类适配器模式使用的是继承的方式，当然这么做的坏处就是失去了使用组合的弹性。
　　所以在实际过程中需要根据使用情况而定，如果 Adaptee 类的行为很复杂，但是 Adapter 适配器类并不需要这些大部分的无关行为，那么使用对象适配器模式是合适的，但是如果需要重新实现大部分 Adaptee 的行为，那么就要考虑是否使用类适配器模式了。

示例与源码

类适配器模式

　　我们以最上面说到的香港的英式三角插座和大陆的三角插座为例，来构造类适配器模式，首先是两个插座格式类：

IChinaOutlet.class

public interface IChinaOutlet {
    public String getChinaType();
}

ChinaOutlet.class

public class ChinaOutlet implements IChinaOutlet{
    @Override
    public String getChinaType() {
        return "Chinese three - pin socket";
    }
}

上面是中式插座的输出格式，然后是香港的英式插座输出格式：

HKOutlet.class

public class HKOutlet {
    public String getHKType() {
        return "British three - pin socket";
    }
}

为了将香港的英式插座转换为中式插座，我们需要构造一个 Adapter 类，目的是进行插座格式的转换：

OutletAdapter.class

public class OutletAdapter extends HKOutlet implements IChinaOutlet{
    @Override
    public String getChinaType() {
        String type = getHKType();
        type = type.replace("Chinese", "British");
        return type;
    }
}

这样就实现了插座接口的转换，例子很简单，明了。当然这个例子很简单，要的就是要学会这个思想：在不修改原来类的基础上，将原来类进行扩展后使用在新的目标系统上。

对象适配器模式

对象适配器模式就以我几年前写过的一个 View 作为例子：android一个转盘效果的容器viewgroup，这个例子就是典型的“需要统一的输出接口，而输入端的类型不可预知”情形，需要输出的是一个个 View ，而输入的数据是未知的。原先的处理方式是使用动态 addChild 的方式添加子 View，然后使用removeChild 方法删除子 View ：

...
public void addChild(final View view) throws NumberOverFlowException{
    if(childNum < maxNum){
        //每次添加子view的时候都要重新计算location数组
        location.add(new FloatWithFlag());
        TurnPlateViewUtil.getLocationByNum(location);
        view.setOnClickListener(new OnClickListener() {

            @Override
            public void onClick(View arg0) {
                listener.onClick((String)arg0.getTag());
            }
        });
        view.setOnLongClickListener(new OnLongClickListener() {

            @Override
            public boolean onLongClick(View arg0) {
                initPopUpWindow();
                window.showAsDropDown(arg0);
                viewIsBeingLongClick = arg0;
                return false;
            }
        });
        addView(view);
        childNum++;
    }else{
        throw new NumberOverFlowException(maxNum);
    }
}

public void removeChild(final View view){
    try{
        this.removeView(view);
        location.remove(0);
        childNum--;
        TurnPlateViewUtil.getLocationByNum(location);
        requestLayout();
    }catch(Exception e){

    }
}
...

使用这种方式会造成外部对子 View 的操纵很繁琐，换位思考一下，如果 ListView 需要以 addView 和 removeView 的方式去处理，那是极其头疼的，所以现在我们可以换一种思维进行改进，学习 ListView 的 Adapter 思想，我们也使用适配器的方式进行处理，为了方便这里就直接继承 BaseAdapter 吧，改造后的代码如下：

/**
 * 设置适配器
 * @param adapter
 */
public void setAdapter(BaseAdapter adapter) throws NumberOverFlowException {
    this.adapter = adapter;
    if (adapter.getCount() > MAX_NUM) {
        throw new NumberOverFlowException(adapter.getCount());
    }
    adapter.registerDataSetObserver(new DataSetObserver() {
        @Override
        public void onChanged() {
            super.onChanged();
            onDataSetChanged();
        }

        @Override
        public void onInvalidated() {
            super.onInvalidated();
            onDataSetChanged();
        }
    });
    initChild();
}

/**
 * 数据源发生变更，需要重新绘制布局
 */
private void onDataSetChanged(){
    initChild();
}
...
private void initChild() {
    removeAllViews();
    location.clear();

    for (int i=0; i < adapter.getCount(); i++) {
        //每次添加子view的时候都要重新计算location数组
        location.add(new FloatWithFlag());
        TurnPlateViewUtil.getLocationByNum(location);
        View view = adapter.getView(i, null, this);
        view.setTag(i);
        view.setOnClickListener(new OnClickListener() {

            @Override
            public void onClick(View arg0) {
                listener.onClick((String)arg0.getTag());
            }
        });
        view.setOnLongClickListener(new OnLongClickListener() {

            @Override
            public boolean onLongClick(View arg0) {
                initPopUpWindow();
                window.showAsDropDown(arg0);
                viewIsBeingLongClick = arg0;
                return false;
            }
        });
        addView(view);
    }
}

外部使用时直接继承 BaseAdapter 类，然后在对应方法中返回对应 View 即可，这样就实现了“不同的输入，同样的输出”：

private class TurnPlateViewAdapter extends BaseAdapter{

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

    @Override
    public Object getItem(int position) {
        return null;
    }

    @Override
    public long getItemId(int position) {
        return 0;
    }

    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        final Drawable drawable = getResources().getDrawable(R.mipmap.ic_launcher);
        drawable.setBounds(0, 0,drawable.getMinimumHeight() , drawable.getMinimumHeight());
        TextView textview = new TextView(MainActivity.this);
        textview.setTextColor(getResources().getColor(android.R.color.white));
        textview.setText(R.string.text);
        textview.setCompoundDrawables(null, drawable, null, null);
        textview.setTag(tag++ +"");
        return textview;
    }
}

这样，外部修改输入数据之后，通知 adapter 数据源变更，因为已经注册观察者，所以 TurnplateView 自然而然可以收到通知，并且刷新界面，最后实现效果和以前一样：

è¿éåå¾çæè¿°

　　由此感慨，在最初学习 android 的时候，listView 的 adapter 知道怎么使用，但是并没有去深究为什么这么使用，其实里面很多地方都透着设计模式的思想，源码真可谓是第一手学习资料。

总结

　　Adapter 模式的经典实现在于将原本不兼容的接口融合在一起，使之能够很好的进行合作。但是，在实际开发中， Adapter 模式也会可以根据实际情况进行适当的变更，最典型的就是 ListView 和 RecyclerView 了，这种设计方式使得整个 UI 架构变得非常灵活，能够拥抱变化。所以在实际使用的时候，遵循上面说过的三种场景：

系统需要使用现有的类，而此类的接口不符合系统的需要，即接口不兼容；
想要建立一个可以重复使用的类，用于与一些彼此之间没有太大联系的一些类，包括一些可能在将来引进的类一起工作；
需要一个统一的输出接口，而输入端的类型不可预知。

根据情况进行变化，将适配器模式灵活运用在实际开发中。
总结下来，Adapter 模式的优点基本已经明确了：

更好的复用性

系统需要使用现有的类，而此类的接口不符合系统的需要，那么通过适配器模式就可以让这些功能得到更好的复用；

更好的扩展性

在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。

总结一下就是对扩展开放和对修改关闭的开闭原则吧。
　　当然适配器模式也有一些缺点，如果在一个系统中过多的使用适配器模式，会让系统非常零乱，不易整体把握。例如，明明看到调用的是Ａ接口，其实内部被适配成 B 类的实现，这样就增加了维护性，过多的使用就显得很没有必要了，不如直接对系统进行重构。

适配器 VS 装饰者 VS 桥接 VS 代理 VS 外观

　　这几个都是结构型设计模式，他们有些类似，在实际使用过程中也容易搞混，我们在这就给他们做一个对比：

适配器模式

　　适配器模式和其他三个设计模式一般不容易搞混，它的作用是将原来不兼容的两个类融合在一起，uml 图也和其他的差别很大。

uml 类图：

è¿éåå¾çæè¿°

装饰者模式

　　装饰者模式结构上类似于代理模式，但是和代理模式的目的是不一样的，装饰者是用来动态地给一个对象添加一些额外的职责，装饰者模式为对象加上行为，而代理则是控制访问。

uml 类图：

è¿éåå¾çæè¿°

桥接模式

　　桥接模式的目的是为了将抽象部分与实现部分分离，使他们都可以独立地进行变化，所以说他们两个部分是独立的，没有实现自同一个接口，这是桥接模式与代理模式，装饰者模式的区别。

uml 类图：

è¿éåå¾çæè¿°

代理模式

　　代理模式为另一个对象提供代表，以便控制客户对对象的访问，管理的方式有很多种，比如远程代理和虚拟代理等，这个在上面有，这里就不说了，而装饰者模式则是为了扩展对象。

uml 类图：

è¿éåå¾çæè¿°

外观模式

　　外观模式提供一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。

　　适配器模式将一个或多个类接口变成客户端所期望的一个接口，虽然大多数资料所采用的例子中适配器只适配一个类，但是你可以适配许多类来提供一个接口让客户端访问；类似的，外观模式也可以只针对一个拥有复杂接口的类提供简化的接口，两种模式的差异，不在于他们“包装”了几个类，而是在于它们的意图。适配器模式的意图是，改变”接口符合客户的期望；而外观模式的意图是，提供子系统的一个简化接口。

uml类图：

è¿éåå¾çæè¿°