设计模式04 —— 适配器模式

设计模式04 —— 适配器模式

本教程参考：菜鸟教程 - 学的不仅是技术，更是梦想！ (runoob.com)

参考书：《图解设计模式》

本系列为本人学习笔记，和课程学习笔记，资料和参考均源自互联网，希望各位大佬多多指点！

介绍

适配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。

这种模式提供了一种单一的类，专门用来负责不兼容的接口和功能。

比如“转接头”，可以将USB转化成Type-C，就是一个独立地用来进行适配的工具。

意图：将一个类的接口转换成希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

主要解决：主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。

何时使用： 1、系统需要使用现有的类，而此类的接口不符合系统的需要。 2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。 3、通过接口转换，将一个类插入另一个类系中。

如何解决：继承或依赖（推荐）。

关键代码：适配器继承或依赖已有的对象，实现想要的目标接口。

应用实例： 1、美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。 2、JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将以前系统的 Enumeration 接口转化为 Iterator 接口，这时就需要适配器模式。 3、在 LINUX 上运行 WINDOWS 程序。 4、JAVA 中的 jdbc。

优点： 1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好。

缺点： 1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。

使用场景：有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。

注意事项：适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。

Adapter模式分类介绍

类适配器模式（使用继承的适配器）

类图：

目前，有一个Banner类，实现了两种方法，showWithParen和showWithAster。

而我们现在有一个实际应用中，有需求的接口，Print，要求我们能够将一个Banner类适配到这个新的需求上

此时，我们就需要定义一个类适配器，PrintBanner类，继承(extends)自Banner，又实现(implements)了Print这个抽象类，在PrintBanner内部进行Banner到Print的适配

在实际应用的过程中，我们在Main函数里，有如下的定义：

可以看到，我们将PrintBanner这个类的实例保存在了一个Print类型的变量中，而在使用的过程中，我们使用的也都是Print这个接口里的方法进行编程的。

所以Banner这个类相当于对Main这个类隐藏起来了。对于手机来说，PrintBanner就像是充电器，我们只需要知道“充电”(即Print)需要用到“电源插头”(即PrintBanner)即可，而电源插头需要充电，有“插入插座”和“插入手机”两个方法(即Print中的printWeak和printStrong)，对于使用者来说，根本不需要知道电源内部的电路构造是如何实现的。而硬件的生产商，也可以通过“优化电源插头”这一个方式，来实现产品的迭代(比如快充)而不需要修改每个用户的手机。

对象适配器模式（使用委托的适配器）

首先解释一下委托的含义，委托其实就是“交给其他人”。

在这个例子中，我们假设之前的Print不再是一个接口了，而是一个类。

但是在Java中，只能单一继承，不能多继承，所以我们没办法再像之前一样PrintBanner extends Banner implements Print了。

在之前的例子中，我们直接在PrintBanner类的构造函数中生成并保存了一个banner类的实例，之后在PrintBanner类的printWeak等方法中调用了banner实例的showWithParen方法。

在这里，我们形成委托的关系，当PrintBanner类的printWeak等方法被调用的时候，我们不将这个方法交给类自己处理，而是委托给一个自己构造的其他Banner类的实例进行处理，来回避“无法多继承”的问题。

注意事项

什么时候使用Adapter模式

在“已有的程序“上进行新的迭代和更新的时候。特别是当现有的类已经被充分地测试过了并且广泛地应用于软件之中了，我们更多情况下希望这些类被复用。

如果出了问题，我们只需要排查适配器即可，在已经知道Bug不在已有的类之后。

也可以进行与旧版本的兼容问题。