适配器模式最接地气的实例

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

引用网上的一个例子：笔记本电脑电源一般用的都是5V电压，但是我们的家用电是220V，我们要让笔记本充上电，最好的办法应该是通过一个工具把220V的电压转换成5V，这个工具就是适配器

好好理解一下设计模式的使用场景比起去记住代码是怎样写的效果要好很多，说不定你哪天编码的时候灵光一现用上了，那就是你真正掌握了。

适配器模式的种类

1. 类适配器

UML图(强烈建议大家去了解一下UML图，它很简单粗暴的把类与类之间的关系描述的很清楚易懂)

image

我们可以看到，目标接口 Target 就相当于是上面的5V电压，Adaptee 就是被适配的220V电压，Adapter 就是适配器。看代码：

image

输出结果：

充5V电啦
 充220V电啦

结合上面给点UML图稍微分析一下：

Adapter类 继承了 Adaptee220V类 然后实现了接口 Target5V 并实现了目标方法 chong5V()，类适配器的一个特点就是 Adapter 会去继承被适配类，这样适配器就直接拥有了被适配类中的方法，所以类适配器的缺点就是不够灵活，让我们看一下另外一种适配器。

2. 对象适配器

image

UML图

这里的 Target 依然是 5V电压，Adaptee 依然是 220V电压，比起类适配器，Adapter 和 Adaptee 的关系从继承变成了组合，上代码：

image

输出结果：

充5V电啦
 充220V电啦

这里我们把 Adaptee220V 通过 Adapter 的构造方法传入到 Adapter 中，当调用 Adapter 的 chong220V()方法 时，实际是调用传进来 Adaptee220V 对象的 chong220V 方法，这样就会变得很灵活。

项目中的运用

之所以写这篇关于适配器设计模式的文章，是因为作者在以前有一次实际开发中，在没有学习过适配器模式的前提下，为了解决项目中的一个开发痛点，自己费劲脑筋想出来的一种模式，到现在才知道原来这个叫适配器模式，在学习了这个设计模式之后更加深入了解了一下。接下来，就来演示一下作者在实际工作中使用到的变异形态的对象适配器模式。

当时开发场景：当时作者开发一个基于POS机的APP，APP要求有打印功能，像订单打印、日期打印等等。我们知道POS机是有多种型号的，每种型号的POS机会有他们单独的SDK，也就是说打印方法是不同的！

image

首先，我们每次调用打印的时候都会先判断 POS机 型号，因为型号不对程序肯定会报错，假如某一天，APP适配的 POS机 类型要增加一款，也就是说我每个判断 POS机 型号的地方都要多家一个if语句，并且还要把 新POS机型 的打印方法加上去，如果我有5个地方用到了打印，就要加5次，这样是很痛苦的，别问我为什么知道。。。经过2次这样的真实情况发生后，我暴走了，痛定思痛要想个办法结局，于是有了以下代码：

image

每种 POS机 都实现 IPrint 中的打印方法：

image

这里我把 POS机 型号判断的代码放到了 PrintManager 的构造方法中，每次 **new **出实例时就会去判断。然后我让 PrintManager 也实现了IPrint接口，因为我认为项目中的打印管理类必须要拥有这三种打印方法。

image

发现没，改过之后的代码，在不同的调用的地方再也不用担心新增POS机型需要改代码了，只需要在 PrintManager 的构造方法中增加一个判断就好了。要是改成单例：

image

改完之后我哭了。。。我他吗的是个天才啊。。。后面果然加了多款POS机，但是我再也不痛苦了！看一下我的UML图：

image

其实，光看UML图，作者在项目中的这种写法已经不算是适配器模式了，因为 Adaptee 已经直接实现了Target中的方法，也就是说根本就不存在不满足目标接口这个说法了。。不过作者这样写完全是自己想出来的，没有基于任何设计模式，就现在目前的效果来说还是不错的，通过这篇文章，我对于适配器模式有了一个清晰的理解，同时也反思了一下我这种写法，还是很有收获的。