一 概述
定义：适配器模式将某个类的接口转换成客户端期望的另一个接口表示，主的目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)。
属于结构型模式
主要分为三类：类适配器模式、对象的适配器模式、接口的适配器模式。
本文定义：
需要被适配的类、接口、对象（我们有的），简称src（source）
最终需要的输出（我们想要的），简称dst(destination，即Target)
适配器称之为Adapter。
一句话描述适配器模式的感觉：src->Adapter->dst,即src以某种形式（三种形式分别对应三种适配器模式）给到Adapter里，最终转化成了dst。
拿我们Android开发最熟悉的展示列表数据的三大控件：ListView，GridView，RecyclerView的Adapter来说，它们三个控件需要的是View(dst),而我们有的一般是datas(src),所以适配器Adapter就是完成了数据源datas 转化成 ItemView的工作。
带入src->Adapter->dst中，即datas->Adapter->View.
使用场景：
1 系统需要使用现有的类，而这些类的接口不符合系统的需要。
2 想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。
3 需要一个统一的输出接口，而输入端的类型不可预知。
二 类适配器模式：
一句话描述：Adapter类，通过继承src类，实现dst 类接口，完成src->dst的适配。
别的文章都用生活中充电器的例子来讲解适配器，的确，这是个极佳的举例，本文也不能免俗：
充电器本身相当于Adapter，220V交流电相当于src，我们的目dst标是5V直流电。
UserAdapter不仅实现了UserInterface接口，同时还继承了UserInfo类。在实现接口的getName()和getTelNumber()方法中，分别调用了UserInfo类中的相应方法并取得结果。由此可以满足需求。在上述定义中，按照UserInterface、UserInfo和UserAdapter在场景中的目的不同，可以具体划分成如下角色：
UserInterface：目标角色——目标接口，系统所期待实现的目标；
UserInfo：源角色——当前已经存在的原有的实现类，即将被适配的类；
UserAdapter：适配器角色——将原有实现装换为目标接口的实现。
简单点说，适配器模式是指：定义一个类，将一个已经存在的类，转换成目标接口所期望的行为形式。
在具体的实现过程中，又可以基于其实现层次是类层次还是对象层次，将其分为类适配器和对象适配器。如上所写的是类适配器。
对象适配器使用组合代替继承，将源角色视为适配器角色的属性：
总体而言：适配器模式是指定义一个适配器类，将一个已经存在的类，转换成目标接口所期望的行为形式。同时，一般来说，基于更多的推荐使用组合而不是继承，因此，对象适配器可能使用更多。
类适配器和对象适配器的选择
从实现上：类适配器使用对象继承的方式，属于静态的定义方式。对象适配器使用对象组合的方式，属于动态组合的方式；
从工作模式上：类适配器直接继承了 Adaptee，使得适配器不能和 Adaptee 的子类一起工作。对象适配器允许一个 Adapter 和多个 Adaptee，包括 Adaptee 和它所有的子类一起工作；
从定义角度：类适配器可以重定义 Adaptee 的部分行为，相当于子类覆盖父类的部分实现方法。对象适配器要重定义 Adaptee 很困难；
从开发角度：类适配器仅仅引入了一个对象，并不需要额外的引用来间接得到 Adaptee。对象适配器需要额外的引用来间接得到 Adaptee。
总的来说，建议使用对象适配器方式。
适配器模式使用注意事项
充当适配器角色的类就是：实现已有接口的抽象类；
为什么要用抽象类？此类是不要被实例化的。而只充当适配器的角色，也就为其子类提供了一个共同的接口，但其子类又可以将精力只集中在其感兴趣的地方。
适配器模式中被适配的接口 Adaptee 和适配成为的接口 Target 是没有关联的，Adaptee 和 Target 中的方法既可以是相同的，也可以是不同的。
适配器在适配的时候，可以适配多个 Apaptee，也就是说实现某个新的 Target 的功能的时候，需要调用多个模块的功能，适配多个模块的功能才能满足新接口的要求。
适配器有一个潜在的问题，就是被适配的对象不再兼容 Adaptee 的接口，因为适配器只是实现了 Target 的接口。这导致并不是所有 Adaptee 对象可以被使用的地方都能是使用适配器，双向适配器解决了这个问题。
优点
适配器模式也是一种包装模式，它与装饰模式同样具有包装的功能，此外，对象适配器模式还具有委托的意思。总的来说，适配器模式属于补偿模式，专用来在系统后期扩展、修改时使用。
缺点
过多的使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。
适配器模式应用场景
在软件开发中，也就是系统的数据和行为都正确，但接口不相符时，我们应该考虑用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。比如在需要对早期代码复用一些功能等应用上很有实际价值。适用场景大致包含三类：
1、已经存在的类的接口不符合我们的需求；
2、创建一个可以复用的类，使得该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作；
3、在不对每一个都进行子类化以匹配它们的接口的情况下，使用一些已经存在的子类。
Java I/O 库大量使用了适配器模式，例如 ByteArrayInputStream 是一个适配器类，它继承了 InputStream 的接口，并且封装了一个 byte 数组。换言之，它将一个 byte 数组的接口适配成 InputStream 流处理器的接口。
我们知道 Java 语言支持四种类型：Java 接口，Java 类，Java 数组，原始类型（即 int,float 等）。前三种是引用类型，类和数组的实例是对象，原始类型的值不是对象。也即，Java 语言的数组是像所有的其他对象一样的对象，而不管数组中所存储的元素类型是什么。这样一来的话，ByteArrayInputStream 就符合适配器模式的描述，是一个对象形式的适配器类。FileInputStream 是一个适配器类。在 FileInputStream 继承了 InputStrem 类型，同时持有一个对 FileDiscriptor 的引用。这是将一个 FileDiscriptor 对象适配成 InputStrem 类型的对象形式的适配器模式。
同样地，在 OutputStream 类型中，所有的原始流处理器都是适配器类。ByteArrayOutputStream 继承了 OutputStream 类型，同时持有一个对 byte 数组的引用。它一个 byte 数组的接口适配成 OutputString 类型的接口，因此也是一个对象形式的适配器模式的应用。
FileOutputStream 继承了 OutputStream 类型，同时持有一个对 FileDiscriptor 对象的引用。这是一个将 FileDiscriptor 接口适配成 OutputStream 接口形式的对象型适配器模式。
Reader 类型的原始流处理器都是适配器模式的应用。StringReader 是一个适配器类，StringReader 类继承了 Reader 类型，持有一个对 String 对象的引用。它将 String 的接口适配成 Reader 类型的接口。
Spring 中使用适配器模式的典型应用
在 Spring 的 AOP 里通过使用的 Advice（通知）来增强被代理类的功能。Spring 实现这一 AOP 功能的原理就使用代理模式（1、JDK 动态代理。2、CGLib 字节码生成技术代理。）对类进行方法级别的切面增强，即，生成被代理类的代理类，并在代理类的方法前，设置拦截器，通过执行拦截器中的内容增强了代理方法的功能，实现的面向切面编程。
Advice（通知）的类型有：BeforeAdvice、AfterReturningAdvice、ThrowSadvice 等。每个类型 Advice（通知）都有对应的拦截器，MethodBeforeAdviceInterceptor、AfterReturningAdviceInterceptor、ThrowsAdviceInterceptor。Spring 需要将每个 Advice（通知）都封装成对应的拦截器类型，返回给容器，所以需要使用适配器模式对 Advice 进行转换。
http://www.ibm.com/developerworks/cn/java/j-lo-adapter-pattern/index.html
