适配器模式
适配器模式（Adapter Pattern）的定义如下：
Convert the interface of a class into another interface clients expect.Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.（将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。）
适配器模式又叫变压器模式，也叫做包装模式（Wrapper），但是包装模式可不止一个，还包括装饰器模式。
适配器模式的通用类图
适配器模式在生活中还是很常见得，比如笔记本上的电源适配器，可以在 100 ~ 220V 之间的电源下正常使用，这也是适配器一个良好模式的体现，简单地说，适配器模式就是把一个接口或类转换成其它的接口或类，从另一方面来说，适配器模式也就是一个包装模式，为什么这么说呢？它把 Adapter 包装成一个 Target 接口的类，加了一层外壳。我们都知道，设计模式原本是为建筑设计而服务的，软件设计模式只是借用了人家的原理而已，那我们来看看最原始的适配器是如何设计的。
A、B 两个图框代表已经塑模成型的物体 A 和物体 B，那现在要求把 A 和 B 安装在一起使用，如何安装？两者的接口不一致，是不可能安装在一起使用的，那怎么办？引入一个物体 C，如下如：
引入物体 C 后，C 适应了物体 A 的接口，同时也适应了物体 B 的接口，然后三者就可以组合成一个完整的物体，如下图：
其中的物体 C 就是我们说的适配器，它在中间起到了角色转换的作用，把原有的长条形接口转换成了三角形接口。在软件行业的设计模式中，适配器模式也是相似的功能，我们现在就来看看适配器模式的三个角色。
Target 目标角色
该角色定义把其它类转换为何种接口，也就是我们的期望接口，例子中的 IUserInfo 接口就是目标角色。
Adaptee 源角色
你想把谁转换成目标角色，这个“谁”就是源角色，它是已经存在的、运行良好的类或对象，经过适配器角色的包装，它会成为一个崭新的角色。
Adapter 适配器角色
适配器模式的核心角色，其它两个角色都是已经存在的角色，而适配器角色是需要新建立的，它的职责非常简单：把源角色转换为目标角色，可通过继承或类关联的方式进行转换。
各个角色的职责都已经非常清楚，我们再来看看其通用源码，目标接口代码如下：
public interface Target {
/**
* 目标角色的行为
*/
public void request();
}目标角色是一个已经在正式运行的角色，你不可以去修改该角色中的任何方法，你能做的就是如何去实现接口中的方法，而且通常情况下，目标角色是一个接口或抽象类，一般不会是实现类。一个正在服役的目标角色代码如下：
public class ConcreteTarget implements Target{
@Override
public void request() {
// do something
}
}源角色也是已经在服役状态（当然，非要新建一个源角色，然后套用适配器模式，那也是没有任何问题的），它是一个正常类，其源代码如下：
public class Adaptee {
/**
* 原有的业务逻辑
*/
public void doSomething() {
// do something
}
}适配器角色源代码如下：
public class Adapter extends Adaptee implements Target {
/**
* 通过继承方式将 Adaptee 源角色行为与 Target 目标角色行为关联，
* 通过这种方式实现 Adaptee 与 Target 之间一系列转换
*/
@Override
public void request() {
super.doSomething();
}
}适配器模式的优点
适配器模式可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就行。
增加了类的透明性
想想看，我们访问的 Target 目标角色，但是具体的实现都委托给了源角色，而这些对高层次模块是透明的，也是它不需要关心的。
提高了类的复用性
源角色在原有的系统中还是可以正常使用，在目标角色中也可以充当新的演员。
灵活性非常好
适配器角色对源角色和目标角色是无侵入的，所以当某天你不再想使用它的时候，可以删除这个适配器。
适配器模式的使用场景
适配器应用的场景只要记住一点就足够了：你有动机修改一个已经投产了的接口时，适配器模式可能是最适合你的模式。比如系统扩展了，需要使用一个以后或新建立的类，但这个类又不符合系统的接口，此时就可以使用适配器模式。
适配器模式的注意事项
适配器模式最好在详细设计阶段不要考虑它，它不是为了解决还处在开发阶段的问题，而是解决正在服役的项目问题，没有一个系统分析师会在做详细设计的时候考虑使用适配器模式，这个模式使用的主要场景是扩展应用，就像我们上面的例子一样，系统扩展了，不符合原有设计的时候才考虑通过适配器模式减少代码修改带来的风险。
再次提醒一点，项目一定要遵守依赖倒置原则和里氏替换原则，否则即使在适合使用适配器的场合下，也会带来非常大的改造。
适配器模式的扩展
适配器模式又分为类适配器和对象适配器，前面演示的适配器是通过继承进行适配，叫做类适配器。对象适配器是将原有的继承关系变为关联关系，通过对象的关联关系进行适配。对象适配器与类适配器的区别是：类适配器是类间继承，对象适配器是对象的合成关系，也可以说是类的关联关系，这是两者的根本区别。二者在实际项目中会经常用到，由于对象适配器是通过类间的关联关系进行耦合的，因此在设计时就可以做到比较灵活，比如修补源角色的隐形缺陷，关联其它对象等，而类适配器就只能通过覆写源角色的方法进行扩展，在实际项目中，对象适配器使用的场景相对较多。
最终实践
适配器模式是一个补偿模式，或者说是一个“补救”模式，通常用来解决接口不相容的问题，在百分之百的完美设计中不可能使用到的，什么是百分之百的完美设计？“千虑”而没有“一失”的设计，但是，再完美的设计也会遇到“需求”变更这个无法逃避的问题，不管我们的系统设计得有多美完美，都无法逃避新业务的发生，技术只是一个工具而已，是因为它推动了其它行业的进步和发展才具有了价值，通俗的说，技术是为业务服务的，因此业务再日新月异变化的同时，也对技术提出了相同的要求，在这种要求下，就需要我们有一种或一些这样的补救模式，保证系统在生命周期内能够稳定、可靠、健壮的运行，而适配器模式就是这样的一个“救世主”，它在需求巨变、业务飞速而导致你极度郁闷、烦躁、崩溃的时候横空出世，它通过把非本系统接口的对象包装成本系统可以接收的对象，从而简化了系统大规模变更的风险的存在。
摘自：《设计模式之禅》(第 2 版)