适配器模式

定义

将一个类的接口,转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间

要点

• 当需要使用一个现有的类而其接口并不符合你的需求时，就使用适配器
• 适配器改变接口以符合客户的期望
• 适配器有两种形式：对象适配器和类适配器。类适配器需要用到多重继承。

适配器(有两种)

结构图如下:

• 类适配器

类适配器.png

• 对象适配器

对象适配器.png

它们之间的区别

• 类适配器继承了Target和Adaptee
• 而对象适配器利用组合的方式将请求传送给被适配者

外观模式

定义

提供了一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让子系统更容易使用。

要点

• 当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观
• 外观将客户从一个复杂的子系统中解耦
• 实现外观需要将子系统组合进外观中，然后将工作委托给子系统执行

从它的定义上来看其实很好理解,外观的意图是要提供一个简单的接口,好让一个子系统更易于使用。如下为这个模式的类图:

外观模式.png

设计原则

• “最少知识”原则
  告诉我们要减少对象之间的交互,只留下几个“密友”,只和你的密友交谈。这个原则是希望我们在设计中,不要让太多的类耦合在一起，免得修改系统中一部分，会影响到其他部分。如果许多类之间相互依赖，那么这个系统就会变成一个易碎的系统，它需要花费很大成本去维护，也会因为太复杂而不容易被其他人了解。

那么如何不要让太多的类耦合在一起?

就任何对象而言，在该对象的方法内，我们只应该调用属于以下范围的方法:

• 该对象本身

• 被当作方法的参数而传递进来的对象

• 此方法所创建或实例化的任何对象
  
  以上这些方针告诉我们,如果某对象是调用其它的方法的返回结果,不要调用该对象的方法

• 对象的任何组件
  
  把“组件”想象成是被实例变量所引用的任何对象

那么如果调用从另一个调用中返回的对象的方法，会有什么害处?如果这样做，就相当于向另一个对象的子部分发出请求。在这种情况下，原则要我们改为要求该对象为我们做出请求，这样的话，我们就不需要认识该对象的组件了，如下例子:

不采用这样的原则:

public float getTemp(){
    Thermometer thermometer = station.getThermometer();
    return thermometer.getTemperature();
}

我们从气象站获取温度计,再从温度计对象取得温度。

采用这样的原则:

public float getTemp(){
    return station.getTemperature();
}

我们在气象站中加进一个方法,用来向温度计请求温度。这可以减少我们所依赖的类的数目。

适配器、外观、装饰者区别

• 适配器将一个对象包装起来以改变接口
• 装饰者将一个对象包装起来以增加新的行为和责任
• 外观将一群对象“包装”起来以简化其接口