设计模式之适配器模式(Adapter)
适配器模式：将一个类或接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
?
适配器模式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 设计模式 (中国电力出版社)
?
?
?
?
?
?
?