结构型设计模式之适配器模式

适配器模式

在日常生活中，大到空调，小到手机，都需要电力的支持。众所周知，家庭电源的电压是220V，而运送这些电给千家万户使用的高压线的电压一般是在几千伏的范围内。那么，家庭想用电怎么办？这时候就有了变压器，它承担起了电压的转换，解决高压电和家庭电源之间的矛盾。类似这种场景的还有很多，就比如前文说的，我们日常使用的手机，电脑，它们的用电电压一般也就十几伏，而解决手机用电与家庭电压的矛盾的就是电源适配器（AC Adapter）。在设计模式上，也有一种用于解决两个维度间矛盾的模式，我们称之为适配器模式。

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

将一个类的接口转换成客户端所希望的另一个接口。适配器让那些由于接口不兼容的类能够工作在一起。

换个角度想，你想要适配适配者的接口，那么首先你就需要获取到适配者的接口方法，而获取的方式一般就是继承、聚合或者引用。其次，你要提供给目标对象一个适配好的方法，那么你就得让目标对象能够以它定义好的方式透明的调用这个适配方法，此时一般就需要实现目标对象的接口。适配器模式干的就是这种事情。

适配器的参与角色：① 目标抽象类（Target） ② 适配器（Adapter） ③ 适配者（Adaptee）

适配器模式一般分为类适配器、对象适配器、缺省适配器、双向适配器。下面将对其进行一一描述。

类适配器

适配器与适配者间是基于继承（或实现）关系。

如图，适配器类和适配者间是继承关系，与目标抽象类间是实现关系。与前文的思路一样，类适配器是通过继承的方式拿到了适配者的接口方法，并且在这其中，也可以通过适配器去对适配者的方法进行置换或者重新拼装。

这里我们举一个前文提到的变压器的例子，详见代码如下：

HomePowerSupply的availableVoltage()表示家用电源的可用电压，表示Target；

HighVoltagePowerSupply的transmissionVoltage()方法代表高压电源的传输电压，表示Apaptee；

Transformer实现了availableVoltage()方法，并且对高压电压进行了一个转换，表示Adapter；

对象适配器

对象适配器则是会利用引用适配者的方式达到适配器的效果。

如图，适配器与适配者间是聚合的关系，与目标抽象类间是实现的关系。这种方式也与我们前文的思路并不相违背，只不过它是采用引用的方式获取到了适配者的接口方法。当然，对象适配器就不能像类适配器那样，对适配者的接口方法进行置换和重新组装，但它能实现对于多个适配者同时进行适配。

我们对类适配器进行一个改造，得到如下的代码：

基本结构和角色关系同类适配器，但是这里是采用引用的方式对适配者进行依赖。

缺省适配器

如果Target抽象类具有多个待实现方法，但我们真正需要获取或者说真正需要适配的只有Target抽象类中的某一个方法，那么实现Target抽象类的其他方法对我们来说毫无意义，因而我们只能对其它不需要的方法采用一个方法体为空的重写，感觉十分累赘，特别在Target抽象类的抽象方法特别多的时候，代码的可读性是十分让人不敢恭维的。

缺省适配器主要用于解决这个问题，通过对Target抽象类的所有抽象方法进行一个默认重写，然后真正的Adapter则是看情况对缺省适配器进行选择性重写。对这方面感兴趣的读者可以翻阅一下JDK中java.awt.event包下的WindowListener和WindowAdapter的原码，WindowAdapter主要就是承担着一个缺省适配器的角色。

下面是对于java语言的不同版本而产生的两种缺省适配器的实现方式。

jdk1.8以前，在没有接口默认方法的情况下，缺省适配器的实现方式如下图。
参见代码如下：

当然如果这里对于抽象适配者类没有哪个方法要求真实业务适配者类所必须实现的话，则可以考虑将AbstractAdapter声明为非抽象。

而在jdk1.8后，因为lambda表达式的原因，为了兼容不同版本的jdk而提供了缺省接口方法之后，缺省适配器的实现方式变成这样，如下图：

与上图相比，代码变的更简洁，减少了一个抽象的适配类。

参考代码如下：

双向适配器

如果在适配器中，同时包含对适配者和目标对象的引用，使适配者能够通过适配器调用目标类的方法，并且目标类也能通过适配器调用适配者的方法，则我们称其为双向适配器。

结构如下图：

双向适配器的实现较为复杂，典型代码如下：

适配器模式的主要应用场景：

1. 系统需要使用一些现有的、接口不符合系统需要的甚至没有源代码的类。
2. 创建用于和一些彼此之间没有太大关联的类进行通信的类，并且这个类是可以重复使用的。（注：就好比一个系统有个adapter，里面维护了一个Object，Object用于注入一些第三方的类）

适配器模式的优点：

1. 将目标类和适配者类解耦，引入一个适配器则可以对现有代码进行重用，无需修改原有结构。
2. 增加了类的透明度和复用性，对于每个客户端，它可以透明的使用适配者的方法，达到一定的代码重用。
3. 灵活性和扩展性较佳，可以通过配置文件的方式将适配器在配置文件中进行切换，也可以在不修改就够的情况下引入新的适配器。
4. 对于类适配器来说，它还具有可以在适配器中置换或者重新组装适配者方法的优点。
5. 对于对象适配器来说，它还具有可以一次性适配多个适配者，并且根据里氏替换原则，也可以对适配者的子类进行适配的优点。

适配器模式的缺点：

1. 类适配器只能一次适配一个适配者，当然这是基于java，C#等不支持多继承的语言而言。
2. 类适配器的适配者不能为终（final）类。
3. 类适配器的目标抽象类只能为接口，因为已经继承了适配者。
4. 对象适配器无法对适配者的方法进行置换或者重新组装。如果真的非得置换或者重新组装，则得多声明一个适配者的子类，在这个子类中对适配者的方法进行相应操作，然后适配器在对适配者的子类进行引用，实现较为复杂。