适配器模式.docx
《适配器模式.docx》由会员分享，可在线阅读，更多相关《适配器模式.docx（36页珍藏版）》请在冰豆网上搜索。
适配器模式
在计算机编程中，适配器模式（有时候也称包装样式或者包装）将一个类的接口适配成用户所期待的。
一个适配允许通常因为接口不兼容而不能在一起工作的类工作在一起，做法是将类自己的接口包裹在一个已存在的类中。
共有两类适配器模式：
对象适配器模式
--在这种适配器模式中，适配器容纳一个它包裹的类的实例。
在这种情况下，适配器调用被包裹对象的物理实体。
类适配器模式
--这种适配器模式下，适配器继承自已实现的类（一般多重继承）。
将一个类的接口转换成客户希望的另外一个接口。
Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
——GangofFour
基本概念
客户：
需要调用我们的代码的对象。
Adapter模式的宗旨：
保留现有类所提供的服务，向客户提供接口，以满足客户的期望。
主要内容
（1）类适配器：
当客户在接口中定义了他期望的行为时，我们就可以应用适配器模式，提供一个实现该接口的类，并且扩展已有的类，通过创建子类来实现适配。
下面是类适配器的UML图：
（2）对象适配器：
对象适配器”通过组合除了满足“用户期待接口”还降低了代码间的不良耦合。
在工作中推荐使用“对象适配”。
（3）缺省适配器模式：
缺省适配器模式是一种特殊的适配器模式，但这个适配器是由一个抽象类实现的，并且在抽象类中要实现目标接口中所规定的所有方法，但很多方法的实现都是“平庸”的实现，也就是说，这些方法都是空方法。
而具体的子类都要继承此抽象类。
适配器模式核心思想：
把对某些相似的类的操作转化为一个统一的“接口”（这里是比喻的说话）--适配器，或者比喻为一个“界面”，统一或屏蔽了那些类的细节。
适配器模式还构造了一种“机制”，使“适配”的类可以很容易的增减，而不用修改与适配器交互的代码，符合“减少代码间耦合”的设计原则。
以下示例，用接近伪码的PHP语法，演示了一个数据库操作的适配器类，它可以操作MySQL和Oracle数据库，但使用了相同的方法。
由于使用了适配器（Adapter）模式，我们不必关心MySQL和Oracle数据库操作类的不同。
我们还可以方便的添加进SQLite等数据库操作的类，“插入”适配器中，立即就可以用操作MySQL和Oracle相同的方法来操作SQLite数据库了。
//适配器类：
//定义了4个操作所有数据库的方法
Java代码
php
class Db_adapter {
private $db;
function __construct（$db_obj） {
$this->db = $db_obj;
}
function select_record（） {
$this->db->select （）;
}
function insert_record（） {
$this->db->insert （）;
}
function update_record（） {
$this->db->update （）;
}
function delete_record（） {
$this->db->delete （）;
}
}
//MySQL 数据库操作类：
----适配者类
class Mysql {
private $obj_mysql;
function __construct（） {
$obj_mysql = ......
;
}
function select（） {
$obj_mysql->mysql_select （）;
}
function insert（） {
$obj_mysql->mysql_insert （）;
}
function update（） {
$obj_mysql->mysql_update （）;
}
function delete（） {
$obj_mysql->mysql_delete （）;
}
}
//Oracle 数据库操作类：
-----适配者类
class Oracle {
private $obj_oracle;
function __construct（） {
$obj_oracle = ......
;
}
function select（） {
$obj_oracle->oracle_select （）;
}
function insert（） {
$obj_oracle->oracle_insert （）;
}
function update（） {
$obj_oracle->oracle_update （）;
}
function delete（） {
$obj_oracle->oracle_delete （）;
}
}
//操作 MySQL 数据库：
$obj = new Db_adapter（new Mysql（））
$obj->select_record （）;
$obj->insert_record （）;
$obj->update_record （）;
$obj->delete_record （）;
//操作 Oracle 数据库：
$obj = new Db_adapter（new Oracle（））
$obj->select_record （）;
$obj->insert_record （）;
$obj->update_record （）;
$obj->delete_record （）;
?
>
要求：
MySQL、Oracle类，有相同名字、相同个数的方法。
方法内部实现了各自的操作数据库的代码。
转换就是在这里完成的。
增加新的数据库操作：
构造新的类，有相同名字、相同个数的方法。
方法内部实现不被关心（被屏蔽）-不同的数据库实现不同。
小缺点：
新的类，可能因为疏忽，导致方法名字不合要求、个数不同。
为了减少出错的可能，可以改进一下。
方法就是定义一个接口，作为模板来继承，达到规范化。
db_adapter类里的方法，只需要使用interfacedb_driver里函数即可。
Java代码
php
//定义一个接口，
interface Db_driver {
function select（）;
function insert（）;
function update（）;
function delete（）;
}
// 数据库操作类，比如 MySQL，Oracle 必须实现 db_driver 接口的同名方法，从而进行了规范。
class Mysql implements Db_driver {
private $obj_mysql;
function __construct（） {
$obj_mysql = ......
;
}
//这里省略的代码同前边的 MySQL 类
}
class Oracle implements Db_driver {
private $obj_oracle;
function __construct（） {
$obj_oracle = ......
;
}
//这里省略的代码同前边的 Oracle 类
}
?
>
使用的前提：
1．接口中规定了所有要实现的方法
2．但一个要实现此接口的具体类，只用到了其中的几个方法，而其它的方法都是没有用的。
实现方法
1．用一个抽象类实现已有的接口，并实现接口中所规定的所有方法，这些方法的实现可以都是“平庸”实现----空方法；但此类中的方法是具体的方法，而不是抽象方法，否则的话，在具体的子类中仍要实现所有的方法，这就失去了适配器本来的作用。
2．原本要实现接口的子类，只实现1中的抽象类即可，并在其内部实现时，只对其感兴趣的方法进行实现。
注意事项
1．充当适配器角色的类就是：
实现已有接口的抽象类
2．为什么要用抽象类：
此类是不要被实例化的。
而只充当适配器的角色，也就为其子类提供了一个共同的接口，但其子类又可以将精力只集中在其感兴趣的地方。
模式解析
你想使用一个已经存在的适配器模式，而他的接口不符合你的需求。
你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作。
你想使用一些已经存在的子类，但是不可能对每一个都进行子类化已一匹配他们的接口，对象适配器可以适配他的父类接口。
适配器如同一个常见的变压器，也如同电脑的变压器和插线板之间的电源连接线，他们虽然都是3相的，但是电脑后面的插孔却不能直接插到插线板上。
适配器模式的用途
用电器做例子，笔记本电脑的插头一般都是三相的，即除了阳极、阴极外，还有一个地极。
而有些地方的电源插座却只有两极，没有地极。
电源插座与笔记本电脑的电源插头不匹配使得笔记本电脑无法使用。
这时候一个三相到两相的转换器（适配器）就能解决此问题，而这正像是本模式所做的事情。
适配器模式的结构
适配器模式有类的适配器模式和对象的适配器模式两种不同的形式。
1.类适配器模式
类的适配器模式把适配的类的API转换成为目标类的API。
在上图中可以看出，Adaptee类并没有sampleOperation2（）方法，而客户端则期待这个方法。
为使客户端能够使用Adaptee类，提供一个中间环节，即类Adapter，把Adaptee的API与Target类的API衔接起来。
Adapter与Adaptee是继承关系，这决定了这个适配器模式是类的：
模式所涉及的角色有：
● 目标（Target）角色：
这就是所期待得到的接口。
注意：
由于这里讨论的是类适配器模式，因此目标不可以是类。
● 源（Adapee）角色：
现在需要适配的接口。
● 适配器（Adaper）角色：
适配器类是本模式的核心。
适配器把源接口转换成目标接口。
显然，这一角色不可以是接口，而必须是具体类。
源代码
publicinterfaceTarget{//目标（Target）角色
/**
*这是源类Adaptee也有的方法
*/
publicvoidsampleOperation1（）;
/**
*这是源类Adapteee没有的方法
*/
publicvoidsampleOperation2（）;
}
上面给出的是目标角色的源代码，这个角色是以一个JAVA接口的形式实现的。
可以看出，这个接口声明了两个方法：
sampleOperation1（）和sampleOperation2（）。
而源角色Adaptee是一个具体类，它有一个sampleOperation1（）方法，但是没有sampleOperation2（）方法。
publicclassAdaptee{源（Adapee）角色
publicvoidsampleOperation1（）{}
}
适配器角色Adapter扩展了Adaptee,同时又实现了目标（Target）接口。
由于Adaptee没有提供sampleOperation2（）方法，而目标接口又要求这个方法，因此适配器角色Adapter实现了这个方法。
publicclassAdapterextendsAdapteeimplementsTarget{//适配器角色Adapter
/**
*由于源类Adaptee没有方法sampleOperation2（）
*因此适配器补充上这个方法
*/
@Override
publicvoidsampleOperation2（）{
//写相关的代码
}
}
2.对象适配器模式
与类的适配器模式一样，对象的适配器模式把被适配的类的API转换成为目标类的API，与类的适配器模式不同的是，对象的适配器模式不是使用继承关系连接到Adaptee类，而是使用委派关系连接到Adaptee类。
从上图可以看出，Adaptee类并没有sampleOperation2（）方法，而客户端则期待这个方法。
为使客户端能够使用Adaptee类，需要提供一个包装（Wrapper）类Adapter。
这个包装类包装了一个Adaptee的实例，从而此包装类能够把Adaptee的API与Target类的API衔接起来。
Adapter与Adaptee是委派关系，这决定了适配器模式是对象的。
publicinterfaceTarget{//目标类
/**
*这是源类Adaptee也有的方法
*/
publicvoidsampleOperation1（）;
/**
*这是源类Adapteee没有的方法
*/
publicvoidsampleOperation2（）;
}
publicclassAdaptee{//源类
publicvoidsampleOperation1（）{}
}
publicclassAdapter{
privateAdapteeadaptee;
publicAdapter（Adapteeadaptee）{
this.adaptee=adaptee;
}
/***源类Adaptee有方法sampleOperation1
*因此适配器类直接委派即可
*/
publicvoidsampleOperation1（）{
this.adaptee.sampleOperation1（）;//对象适配
}
/***源类Adaptee没有方法sampleOperation2
*因此由适配器类需要补充此方法
*/
publicvoidsampleOperation2（）{
//写相关的代码
}
}
类适配器和对象适配器的权衡
● 类适配器使用对象继承的方式，是静态的定义方式；而对象适配器使用对象组合的方式，是动态组合的方式。
● 对于类适配器，由于适配器直接继承了Adaptee，使得适配器不能和Adaptee的子类一起工作，因为继承是静态的关系，当适配器继承了Adaptee后，就不可能再去处理Adaptee的子类了。
对于对象适配器，一个适配器可以把多种不同的源适配到同一个目标。
换言之，同一个适配器可以把源类和它的子类都适配到目标接口。
因为对象适配器采用的是对象组合的关系，只要对象类型正确，是不是子类都无所谓。
● 对于类适配器，适配器可以重定义Adaptee的部分行为，相当于子类覆盖父类的部分实现方法。
对于对象适配器，要重定义Adaptee的行为比较困难，这种情况下，需要定义Adaptee的子类来实现重定义，然后让适配器组合子类。
虽然重定义Adaptee的行为比较困难，但是想要增加一些新的行为则方便的很，而且新增加的行为可同时适用于所有的源。
● 对于类适配器，仅仅引入了一个对象，并不需要额外的引用来间接得到Adaptee。
对于对象适配器，需要额外的引用来间接得到Adaptee。
建议尽量使用对象适配器的实现方式，多用合成/聚合、少用继承。
当然，具体问题具体分析，根据需要来选用实现方式，最适合的才是最好的。
适配器模式的优点
更好的复用性
系统需要使用现有的类，而此类的接口不符合系统的需要。
那么通过适配器模式就可以让这些功能得到更好的复用。
更好的扩展性
在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。
适配器模式的缺点
过多的使用适配器，会让系统非常零乱，不易整体进行把握。
比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。
因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。
缺省适配模式
缺省适配（DefaultAdapter）模式为一个接口提供缺省实现，这样子类型可以从这个缺省实现进行扩展，而不必从原有接口进行扩展。
作为适配器模式的一个特例，缺省是适配模式在JAVA语言中有着特殊的应用。
鲁智深的故事
和尚要做什么呢？
吃斋、念经、打坐、撞钟、习武等。
如果设计一个和尚接口，给出所有的和尚都需要实现的方法，那么这个接口应当如下：
publicinterface和尚{
publicvoid吃斋（）；
publicvoid念经（）；
publicvoid打坐（）；
publicvoid撞钟（）；
publicvoid习武（）；
publicStringgetName（）;
}
显然，所有的和尚类都应当实现接口所定义的全部方法，不然就根本通不过JAVA语言编辑器。
像下面的鲁智深类就不行。
publicclass鲁智深implements和尚{
publicvoid习武（）{
拳打镇关西；
大闹五台山；
大闹桃花村；
火烧瓦官寺；
倒拔垂杨柳；
}
publicStringgetName（）{
return"鲁智深";
}
}
由于鲁智深只实现了getName（）和习武（）方法，而没有实现任何其他的方法。
因此，它根本就通不过Java语言编译器。
鲁智深类只有实现和尚接口的所有的方法才可以通过Java语言编译器，但是这样一来鲁智深就不再是鲁智深了。
以史为鉴，可以知天下。
研究一下几百年前鲁智深是怎么剃度成和尚的，会对Java编程有很大的启发。
不错，当初鲁达剃度，众僧说：
“此人形容丑恶、相貌凶顽，不可剃度他",但是长老却说：
”此人上应天星、心地刚直。
虽然时下凶顽，命中驳杂，久后却得清净。
证果非凡，汝等皆不及他。
”
原来如此！
看来只要这里也应上一个天星的话，问题就解决了！
使用面向对象的语言来说，“应”者，实现也；“天星”者，抽象类也。
publicabstractclass天星implements和尚{
publicvoid吃斋（）{}
publicvoid念经（）{}
publicvoid打坐（）{}
publicvoid撞钟（）{}
publicvoid习武（）{}
publicStringgetName（）{
returnnull;
}
}
鲁智深类继承抽象类“天星”
publicclass鲁智深extends天星{
publicvoid习武（）{
拳打镇关西；
大闹五台山；
大闹桃花村；
火烧瓦官寺；
倒拔垂杨柳；
}
publicStringgetName（）{
return"鲁智深";
}
}
这个抽象的天星类便是一个适配器类，鲁智深实际上借助于适配器模式达到了剃度的目的。
此适配器类实现了和尚接口所要求的所有方法。
但是与通常的适配器模式不同的是，此适配器类给出的所有的方法的实现都是“平庸”的。
这种“平庸化”的适配器模式称作缺省适配模式。
在很多情况下，必须让一个具体类实现某一个接口，但是这个类又用不到接口所规定的所有的方法。
通常的处理方法是，这个具体类要实现所有的方法，那些有用的方法要有实现，那些没有用的方法也要有空的、平庸的实现。
这些空的方法是一种浪费，有时也是一种混乱。
除非看过这些空方法的代码，程序员可能会以为这些方法不是空的。
即便他知道其中有一些方法是空的，也不一定知道哪些方法是空的，哪些方法不是空的，除非看过这些方法的源代码或是文档。
缺省适配模式可以很好的处理这一情况。
可以设计一个抽象的适配器类实现接口，此抽象类要给接口所要求的每一种方法都提供一个空的方法。
就像帮助了鲁智深的“上应天星”一样，此抽象类可以使它的具体子类免于被迫实现空的方法。
缺省适配模式的结构
缺省适配模式是一种“平庸”化的适配器模式。
publicinterfaceAbstractService{
publicvoidserviceOperation1（）;
publicintserviceOperation2（）;
publicStringserviceOperation3（）;
}
publicclassServiceAdapterimplementsAbstractService{
@Override
publicvoidserviceOperation1（）{
}
@Override
publicintserviceOperation2（）{
return0;
}
@Override
publicStringserviceOperation3（）{
returnnull;
}
}
可以看到，接口AbstractService要求定义三个方法，分别是serviceOperation1（）、serviceOperation2（）、serviceOperation3（）；而抽象适配器类ServiceAdapter则为这三种方法都提供了平庸的实现。
因此，任何继承自抽象类ServiceAdapter的具体类都可以选择它所需要的方法实现，而不必理会其他的不需要的方法。
适配器模式的用意是要改变源的接口，以便于目标接口相容。
缺省适配的用意稍有不同，它是为了方便建立一个不平
升级会员 