设计模式之适配器模式(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 设计模式 (中国电力出版社)