Java设计模式之——适配器模式

适配器模式简单介绍

适配器模式在我们的开发中使用率极高，从代码中随处可见的 Adapter 就可以判断出来。从最早的 ListView、GridView到现在最新的 RecyclerView 都需要使用 Adapter，并且在开发中我们遇到的优化问题、出错概率较大的地方也基本都出自 Adapter，这是个让人又爱又恨的角色。
说到底，适配器是将两个不兼容的类融合在一起，它有点向粘合剂，将不同的东西通过一种转换使得它们能够协作起来。例如，经常碰到要在两个没有关系的类型之间进行交互，第一个解决方案是修改各自类的接口，但是如果没有源代码或者我们不愿意为了一个应用而修改各自的接口，此时怎么办？这种情况我们往往会使用一个 Adapter，在这两种接口之间建立一个“混血儿”接口，这个 Adapter 会将这两个接口进行兼容，在不修改原有代码的情况下满足需求。

适配器模式的定义

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

适配器模式的使用场景

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

适配器模式的 UML 类图

适配器模式分为两种，即类适配器模式和对象适配器模式，首先先来看类适配器模式，结构图如下所示：

如图所示，类适配器是通过实现 Target 接口以及继承 Adapter 类来实现接口转换，例如，目标接口需要的是 operation2，但是 Adapter 对象只有一个 operation3，因此就出现了不兼容的情况，此时通过 Adapter 实现一个 operation2 函数将 Adapter 的 operation3 转换为 Target 需要的 operation2，以此实现兼容。

角色介绍：

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

适配器模式实战

用电源接口做例子，笔记本电脑的电源一般都是用 5V 电压，但是我们生活中的电线电压一般都是 220V。这个时候就出现了不匹配的状况，在软件开发中我们称之为接口不兼容，此时就需要适配器来进行一个接口转换。在软件开发中有一句话正好体现了这点：任何问题都可以加一个中间层来解决。这个层我们可以理解为这里的 Adapter 层，通过这层来进行一个接口转换就达到了兼容的目的。

在上述电源接口这个示例中，5V 电压就是 Target 接口，220V 电压就是 Adaptee 类，而将电压从 220V 转换为 5V 就是 Adapter。

类适配器模式

具体程序如下所示：

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

/**
 * adaptee角色，需要被转换的对象
 */
public class Volt220 {
    public int getVolt220() {
        return 220;
    }
}

/**
 * Adapter 角色，将 220V 的电压转换为 5V 的电压
 */
public class VoltAdapter 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() {
        VoltAdapter adapter = new VoltAdapter();
        Log.d("输出电压", "" + adapter.getVolt5());
    }
}

对象适配器模式

与类适配器模式一样，对象的适配器模式把被适配的类的 API 转换成为目标类的 API，与类的适配器模式不同的是，对象的适配器模式不是使用继承关系连接到 Adaptee 类，而是使用代理关系连接到 Adaptee 类，UML 类图如下所示：

从图中可以看出，Adaptee 类（Volt220）并没有 getVolt5() 方法，而客户端则期待这个方法。为使客户端能够使用 Adaptee 类，需要提供一个包装类 Adapter。这个包装类包装了 Adaptee 的实例，从而此包装类能够把 Adaptee 的 API 与 Target 类的 API 衔接起来。Adapter 与 Adaptee 是委派关系，这决定了适配器模式是对象的。示例代码如下：

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

/**
 * adaptee角色，需要被转换的对象
 */
public class Volt220 {
    public int getVolt220() {
        return 220;
    }
}

/**
 * Adapter 角色，将 220V 的电压转换为 5V 的电压
 */
public class VoltAdapter implements FiveVolt {
    Volt220 mVolt220;

    public VoltAdapter(Volt220 adaptee){
        this.mVolt220 = adaptee;
    }

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

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

使用示例代码如下：

public class Test {
    public static void main() {
        VoltAdapter adapter = new VoltAdapter(new Volt220());
        Log.d("输出电压", "" + adapter.getVolt5());
    }
}

这种实现方式直接将要适配的对象传递到 Adapter 中，使用组合的形式实现接口兼容的效果。这比类适配器方式更为灵活，它的另一个好处是被适配对象中的方法不会暴露出来，而类适配器由于继承了被适配器对象，因此，被适配对象类的函数在 Adapter 类中也都含有，这使得 Adapter 类出现一些奇怪的接口，用户使用成本较高。因此，对象适配器模式更加灵活、使用。

在实际开发中 Adapter 通常应用于进行不兼容的类型转换的场景，还有一种就是输入有无数中情况，但是输出类型是统一的，我们可以通过 Adapter 返回一个统一的输出，而具体的输入留给用户处理，内部只需要知道输出的是符合要求的类型即可。例如 ListView 的 Adapter，用户的 Item View 格式各样，但最终都是属于 View 类型，ListView 只需要知道 getView 返回的是一个 View 即可，具体是什么 View 类型并不要 ListView 关心。而在使用 Adapter 模式的过程中建议尽量使用对象适配器的实现方式，多用合成或者聚合，少用继承。当然，具体问题具体分析，根据需要来选用实现方式，最适合才是最好的。

上面的两个例子并不是很恰当，想要更多了解适配器的朋友可以看下这篇文章，在细细体会下：

Java设计模式透析之 —— 适配器(Adapter)

总结

优点：

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

缺点：

• 过多地使用适配器，会让系统非常凌乱，不宜整体把握。例如，明明开到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此，如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。