适配器模式：将一个类或接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
适配器模式UML图：
适配器模式使用对象组合，包装被适配者：这种做法还有另外一个优点，被适配者的任何子类，都可以搭配着适配器使用。该模式可以通过创建适配器进行接口转换，让不兼容的接口变成兼容，可以让客户从实现的接口解耦。
外观模式：提供一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让调用方只依赖于高层的外观接口，而不需要关注外观接口背后的细节。
外观模式UML图：
设计原则之迪米特原则：只与你直接的朋友通信，不要跟陌生人说话，每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
减少依赖，降低耦合。
遵循迪米特原则的一些常用做法：
就任何对象而言，在该对象的方法内，我们只应该调用属于一下范围的方法：
- 该对象本身
- 被当作方法参数而传递进来的对象
- 此方法中创建或者实例化的任何对象
- 类的实例变量
尽量不要发生类似于如下代码的调用：
/**
* 返回当前温度
* @return
*/
public double getTemp(){
//从气象站返回一个温度计
Thermometer thermometer = station.getThermometer();
//从温度计获知当前温度
return thermometer.getTemperature();
}
对于方法的调用者来说，我只关心当前的气温，至于温度是如何测量的并不被关注，以上代码从气象站返回了一个Thermometer对象，无疑给这个类引入了一个新的依赖Thermometer，我们应该尽量减少依赖，降低耦合度，因此以上代码最好改成以下所示：
/**
* 返回当前温度
* @return
*/
public double getTemp(){
//直接从气象站返回一个温度，至于气象站如何测量到这个温度，用什么工具测量温度，干我鸟事？
return station.getTemperature();
}
如此以来，我们就只需要依赖气象站station，根本不需要关心他是如何测量当前温度的了。
之所以把适配器模式和外观模式放在一起，主要是因为他们很大程度的相似之处：
- 适配器模式：隐藏被适配者，让客户端感觉不到后面的变化
- 外观模式：隐藏一群类的调用，让客户端感觉不到外观后面的变化
除此之外，适配器模式还有一个关键作用是将本不兼容的类或者接口，通过引入适配器，让其能够兼容别的接口，并且还具有透明性，这是该模式的意图所在。
参考资料：
Head First 设计模式 (中国电力出版社)