适配器模式，属于结构性模式，更加关心的是代码的结构和复用，而不是对象的创建。
适配器模式：别名Wrapper，为了将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作。
适配器模式类型：对象适配器，类适配器
1：对象适配器
客户所需要的数据，在提供客户的接口里面没有得到实现。这时候就需要提供新的接口，但是接口在某种环境下不能随便添加（比如线上系统已经稳定，接口对接已经文档化不可随便修改），这个时候就需要用到我们的对象适配器。
对象适配器：用适配器把数据转换成客户需要的数据。
UML图：
本人喜欢玩《完美国际》这款网络游戏，今天就用此游戏为例：我们给用户提供了游戏里面角色的一些接口，比如角色可以跑，跳等，但是每个职业都有跑和跳，我们只提供了对外的一个接口，难不成给客户提供所有职业的跑和跳的类吗？当然是可行的，但是这里客户又不想改变之前的接口形式，怎么办呢？这个时候就需要用到对象适配器。把我们的数据是配成客户所需要的数据。如图：
对外提供的接口类（类，抽象类都可以）：
系统已经存在的资源（也是客户需要的资源）：
对客户接口和系统已有资源做适配（使他们可以在一起工作）：
测试：
分析：代码中 Renwu 接口是对外提供的接口，这个接口可以是类，接口，抽象类，现在要求不改变这个接口的情况下（这里注意）。让接口能提供我们本地资源（武侠和羽芒的功能），所以在这里做一个适配（Adapter类），是外部接口和我们资源在一起工作，把我们本地资源转成了客户需要的接口资源，完全符合适配器原理。
注意点：有人会说这个Adapter不是我们前几篇文章讲的工厂类吗？答案是正确的，这确实是一个工厂类，代码形式基本没有变化，只不过他们的目的不同，工厂类提供我们创建的对象，而适配器使两方资源可以兼容在一起工作。
也有人说这不就是简单的方法内部调用其他引用的资源吗？是的，这就是对象适配器的实现方式，是不是很简单？
2：类适配器
UML:
现在客户有个新需求，我想让上面的羽芒角色，不仅能跳和跑的功能，还想要它有飞翔的功能，其他角色的不变。
方案：
a：在接口里面添加新的抽象方法
b：在羽芒的类中添加普通方法。
c：使用类适配器。
分析：
如果使用a方案，如果接口类很多类去实现，那么修改量过大。
如果使用b方案，有点违背设计模式的基本原理，耦合性过高。
如果使用c方案，推荐。如图：
接口类：
具体实现类：
适配的新接口和适配器：
测试：
以上实例，在不改变老接口的基础上，给实现类添加了新接口实现，使老接口和新接口在一起工作，符合适配器的原理。
总结：有些人说，总感觉适配器模式有种亡羊补牢的意味，在后期给老接口适配新的资源和接口，为什么不提前就把资源和接口定义好呢？是这样的，适配器模式确实有种亡羊补牢的意思，但是需求瞬息万变，适配器有时候也是一种很好的选择。
