一、背景
在软件开发中,我们通常可以通过目标类提供的接口访问这个类提供的服务。有时候现有的类可以满足客户类的功能需求,但是他所提供的接口不一定是客户类所期望的,这可能是因为现有类中方法名与目标类中定义的方法名不一致等原因所导致的。在这种情况下,现有的接口需要转化为客户类期望的接口,这样保证了对现有类的重用。如果不进行这样的转化,客户类就不能利用现有类所提供的功能。
适配器提供客户类需要的接口,适配器的实现就是把客户类的请求转化为对适配者的相应接口的调用。也就是说:当客户类调用适配器的方法时,在适配器类的内部将调用适配者类的方法,而这个过程对客户类是透明的,客户类并不直接访问适配者类。因此,适配器可以使由于接口不兼容而不能交互的类可以一起工作。
二、模式定义
将一个接口转换成客户希望的另一个接口,适配器模式使接口不兼容的那些类可以一起工作。在软件开发中采用类似于电源适配器的设计和编码技巧被称为适配器模式。
模式分析
- 适配器不是在详细设计时添加的,而是解决正在服役的项目的问题。
- 适配器模式有两种实现方式,继承或组合,一般推荐组合的方式,即适配类中持有一个适配者的引用。
三、模式角色和UML类图
目标抽象类(Target):目标抽象类定义客户所需接口,可以是一个抽象类、接口或具体类。
适配器类(Adapter):适配器可以调用另一个接口,作为一个转换器,对Adaptee和Target进行适配,适配器类是适配器模式的核心,在对象适配器中,它通过继承Target并关联一个Adaptee对象使二者产生联系。
适配者类(Adaptee):适配者即被适配的角色,它定义了一个已经存在的接口,这个接口需要适配,适配者类一般是一个具体类,包含了客户希望使用的业务方法,在某些情况下可能没有适配者类的源代码。
代码示例:
假如当前有一个系统,vector中顺序存放系统需要执行的启动功能,这些操作可以由不同的组件提供,这些组件只要实现Target 接口就可以。当前还需要向功能集合中增加一个启动功能,恰好Adaptee 可以提供,但是client不能直接使用,因此我们增加一个适配类Adapter 实现Target,然后Adater持有一个Adaptee 引用即可。
/* 1.适配者类:新的类提供的接口 */
class Adaptee {
public:
void specificRequest() {
cout << "Adaptee's specificRequest." << endl;
}
};
/* 2.目标类:现有系统使用的抽象类 */
class Target {
public:
virtual void request() = 0;
};
//3.系统现有功能类
class ConcreteTarget1 :public Target {
public:
void request(){
cout << "ConcreteTarget1 'request." << endl;
}
};
/* 4.适配器类:使得现有系统可以使用适配者类提供的功能 */
class Adapter :public Target {
public:
Adapter(Adaptee* adaptee) :m_pAdaptee(adaptee) {}
void request() {
m_pAdaptee->specificRequest();
}
private:
Adaptee* m_pAdaptee;
};
/* 5.现有系统一个接口,实现某个功能,如果没有适配类,那么该系统就无法使用适配者类的功能*/
void client(vector<Target*> &targets) {
for(auto t:targets) {
t->request();
}
}
int main() {
vector<Target*> targets = {new ConcreteTarget1()}
Adaptee* adaptee = new Adaptee();
Target* adapter = new Adapter(adaptee);
/* 将新的功能加入功能集合 */
targets.push_back(adapter);
client(targets);
return 0;
}
四、模式总结
使用场景
-
系统需要使用现有的类,而此类的接口不符合系统的需要。
-
想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作,这些源类不一定有一致的接口
-
通过接口转换,将一个类插入另一个类系中。(比如老虎和飞禽,现在多了一个飞虎,在不增加实体的需求下,增加一个适配器,在里面包容一个虎对象,实现飞的接口。)
优点
-
可以让任何两个没有关联的类一起运行,将目标类和适配者类解耦,通过引入一个适配器类来重用现有的适配者类,无须修改原有结构。
-
增加了类的透明性和复用性,将具体的业务实现过程封装在适配者类中,对于客户端类而言是透明的,而且提高了适配者的复用性,同一个适配者类可以在多个不同的系统中复用。
-
灵活性和扩展性都非常好,通过使用配置文件,可以很方便地更换适配器,也可以在不修改原有代码的基础上增加新的适配器类,完全符合“开闭原则”。
缺点
- 过多地使用适配器会让系统非常零乱,不易整体进行把握。比如,明明看到调用的是 A 接口,其实内部被适配成了 B 接口的实现,一个系统如果太多出现这种情况,无异于一场灾难。因此如果不是很有必要,可以不使用适配器,而是直接对系统进行重构。