设计模式Adapter.docx

A:<设计模式>一书中的描述

"将一个类的接口转换成客户希望的另一个接口,Adapter模式使原本由于接口不兼容而不能一起工作的类可以一起工作"

简单的说,就是利用现有的接口去包装一个第三方的接口,使其能象现有接口一样被程序调用,而不考虑实际使用类的差异

举例:

当前系统有一个绘图接口IDraw,其中定义了display()方法,用来显示一个
现在同事A,给我一套新的绘图类,但是这个类却使用了show()方法来显示一个图形
我不能修改这个新接口,因为他被编译了,如果直接使用此接口,我不得不修改主程序以适应这个接口,这是一个繁重的工作
但是,使用Adapter模式,可以根据IDraw接口来创建一个"适配器"
classMyDrawimplementsIDraw{
OtherDrawotherDraw=newOtherDraw();
publicvoiddisplay(){
otherDraw.show();
}
}
现在我们可以调用MyDraw的display()方法来显示图形了,主程序不会意识到下端子系统的变化

Adapter模式与Facade模式很相象
他们都封装了原有的接口

他们之间的区别在于
Facade模式不按照某个接口设计Adapter模式必须按照某个类设计
Facade一般不需要多态行为Adapter模式大多可能是为了现有的多态行为而使用的
Facade是为了简化原有的复杂接口Adapter必须遵循一个已有的接口,不能简化任何东西,即使可能存在更简单的接口

B:意图将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。(GoF)场景相信很多人都知道什么是显卡，也有很多人知道显卡的本名——图形适配器。恩，是的，正好这回说说Apater模式，就拿显卡来例子来分析一下Adapter模式。我们知道显示器(Client)是用来显示图形的，它是不能显示数据，它只能够接受来自图形发送设备Target的信号。可是我们手头上只有CPU(Adaptee)这个产生各种描述图形的数据的数据发送器。我们需要将这些数据让显示器进行显示，可是这两个部件却是不兼容的。于是我们需要一个中间设备，它能够将CPU“适配”于显示器，这便是我们的显卡——图形适配器(Adapter)。
java代码

//图形发送设备
publicclassTarget{
/**
*传送图形信号
*/
publicStringrequest(){
return"Graphicsender";
}
}

java代码

//显示器
publicclassClient{

publicstaticvoidmain(String[]args){
Targettarget=newTargete();
System.out.println(target.request());
}
}
可是我们的CPU(Adaptee)只能输出0/1数据，他是个计算器，而不是图形发送设备(Target)。
java代码

//CPU
publicclassAdaptee{
/**
*CPU输出的数据
*/
publicStringgetData(){
return"CPUdata";
}
}
这个时候我们的显卡(Adapter)的作用便体现出来了，它负责对CPU进行适配，通过将CPU传过来的数据转换成图形信号，从而将CPU伪装成一个图形发送设备。
java代码

//显卡，即我们的适配器
publicclassAdapterextendsTarget{

//被代理的设备
privateAdapteeapt=null;

/**
*装入被代理的设备
*/
publicAdapter(Adapteeapt){
this.apt=apt;
}

/**
*被代理的设备传过来的数据转换成为图形输出
*/
publicStringrequest(){
returnapt.getData();
}
}
这样，我们的电脑的显示流程就变成CPU－显卡－显示器：
java代码

publicclassClient{

publicstaticvoidmain(String[]args){
//CPU经过显卡的适配后“变”成了图形发送装置了
Targettarget=newAdapter(newAdaptee());
System.out.println(target.request());
}

}
上面的这种依赖于对象组合的Adapter模式叫做对象适配器(ObjectAdapter)。它的特征是继承/实现某一方的类(Target)，如这里的图形发送器，同时内部包含一个被适配的类(Adaptee)，如这里的CPU。通过重写其父类的方法来