C++设计模式结构型模式———适配器模式
文章目录
- 一、引言
- 二、适配器模式
- 三、类适配器
- 四、总结
一、引言
适配器模式是一种结构型设计模式,它在日常生活中有着广泛的应用,比如各种转换接头和电源适配器,它们的主要作用是解决接口不兼容的问题。就像使用电源适配器将220V的市电转换为5V电压来给手机充电一样,适配器模式用于解决两个类之间的不兼容问题。在C++ STL(标准模板库)中,适配器是六大组件之一,这六大组件包括容器、算法、迭代器、仿函数、适配器和空间适配器。适配器又可以细分为容器适配器、函数适配器和迭代器适配器。
二、适配器模式
适配器模式能使接口不兼容的对象能够相互合作。
假设公司某个对外提供服务的项目需要记录一些日志信息,以方便运营人员查看或者日后对项目的某些行为进行追溯。日志准备写到一个固定的文件中,于是,程序开发人员向项目中增加了一个LogToFile
类来实现日志文件的相关操作(日志系统),代码如下:
class LogToFile {
public:
void initfile() { /* 初始化文件日志 */ }
void writetofile(const string& message) { /* 写入消息到文件 */ }
void readfromfile() { /* 从文件读取消息 */ }
void closefile() { /* 关闭文件 */ }
//...
};
随着项目规模的不断增加,要记录的日志信息也逐渐增多,单纯地向日志文件中记录日志信息会导致日志文件膨胀得过大,不方便管理和查看,于是准备对项目中的日志系统进行升级改造,从原有的将日志信息写入文件改为将日志信息写入到数据库。改造后的代码如下:
class LogToDatabase {
public:
void initdb() {}
void writetodb(const string&) {}
void readfromdb() {}
void closedb() {}
//...
};
新的日志系统(LogToDatabase
类)是将所有日志信息写人到数据库或者从数据库中读取日志信息,代码中凡是涉及与日志相关的类,也全部从以往的使用LogToFile
类变成了使用LogToDatabase
类。在主函数中,我们这样调用:
LogToDatabase* logdb = new LogToDatabase();
logdb->initdb();
//....
但有一天,突然遇到了一些意外的情况或者出现了一些特殊需求,机房突然断电导致数据库中的数据发生了损坏无法正确读写。需要从以往使用的LogToFile
类所生成的日志文件中读取一些日志信息。
所有使用了LogToDatabase
类的代码行要么无法应付意外发生的情况,要么无法实现特殊需求。所以在这种情况下使用回LogToFile
类可以解决上面的两个问题,至少是能够临时解决。但问题是现在所有项目中的代码使用的都是LogToDatabase
类,而LogToDatabase
类的接口(成员函数)与LogToFile
类的接口又完全不同,怎么办呢?
若把接口全部改回LogToFile
类改动量很大,而且数据库恢复之后又得改回去。若修改LogToDatabase
类,把以往LogToFile
类中实现的功能融合到LogToDatabase
类中来,但是这样也免不了修改调用该类的函数的地方。
此时我们就需要引入适配器模式,在该模式中,通过引入适配器类,把LogToDatabase
类中,诸如对writetodb
、readfromdb
等成员函数的调用转换成对LogToFile
类中,诸如对writetofile
、readfromfile
等成员函数的调用,从而达到直接使用LogToFile
类中的接口的目的。这样做之后,main
主函数中与LogToDatabase
类相关的代码行只需要做非常小的调整,所调用的成员函数名都不需要改变。看一看采用适配器模式后代码如何修改。首先重新实现LogToDatabase
类,但在适配器模式中该类并不是用于读写数据库日志,而是用于作为父类提供一些供子类使用的接口。
class LogToDatabase {
public:
virtual void initdb() = 0;
virtual void writetodb(const string&) = 0;
virtual void readfromdb() = 0;
virtual void closedb() = 0;
virtual ~LogToDatabase(){}
//...
};
上述的LogToDatabase
中定义了一些接口,这些接口都是当前项目中使用的操作日志的接口,我们可以称这些接口为目标接口(新接口)。LogToFile
类的内容不变,其中的成员函数(接口)可以称为老接口。接着引人适配器类LogAdapter
,其父类为LogToDatabase
,应注意该类的构造函数中的形参类型(LogToFile
类型)
class LogAdapter : public LogToDatabase {
public:
LogAdapter(LogToFile log) : m_pfile(make_unique<LogToFile>(log)) {
m_pfile->initfile(); // 初始化文件日志
}
virtual void initdb() override {
// 实现数据库初始化
}
virtual void writetodb(const string& message) override {
m_pfile->writetofile(message); // 将消息适配为文件日志
}
virtual void readfromdb() override {
m_pfile->readfromfile(); // 适配从文件读取
}
virtual void closedb() override {
m_pfile->closefile(); // 关闭文件
}
private:
unique_ptr<LogToFile> m_pfile;
};
此时我们仅对代码进行一小点改动,其中对接口,例如 initdb
、writetodb
等没有发生改动,通过适配器类,实际调用的接口都是文件日志的。
LogToFile logfile;
LogToDatabase* plogdb2 = new LogAdapter(logfile);
plogdb2->initdb();
plogdb2->writetodb("向数据库中写人一条日志,实际是向日志文件中写人一条日志");
plogdb2->readfromdb();
plogdb2->closedb();
delete plogdb2;
引入适配器模式的定义(实现意图):将一个类的接口转换成客户希望的另外一个接口。该模式使得原本因为接口不兼容而不能一起工作的类可以一起工作。
根据上述对LogToDatabase
类接口的调用转换为对LogToFile
类接口的调用:
我们使用了适配器类实现了对接口实际调用的转换。也就是说,当需要把被适配的接口(如writetofile
、readfromfile
)应用到当前环境下,就需要配适配器。
- 目标抽象类(Target):该类定义所需要暴露的接口(诸如initdb、writetodb、readfromdb、closedb等)。这些接口其实就是未来的接口或者说是调用者希望使用的接口,将被客户端或说调用者(例如,上述范例中main主函数中的调用代码)调用。这里指
LogToDatabase
类。 - 适配者类(Adaptee):该类扮演着被适配的角色,其中定义了一个或多个已经存在的接口(老接口),这些接口需要适配(对其他接口的调用转换成对这些接口的调用)。这里指
LogToFile
类(旧类)。在适配器模式中,适配者类不限于一个,也可以有多个。 - 适配器类(Adapter):注意英文字母的拼写区别于Adaptee(适配者类)。适配器类是一个包装类,扮演着转换器的角色,是适配器模式的实现核心,用于调用另一个接口(包装适配者)。该类对 Adaptee 和 Target 进行适配。这里所说的适配,指的就是把客户端针对
LogToDatabase
类中接口的调用转换成对LogToFile
类中接口的调用。适配器类这里指LogAdapter
类。
适配器结构
- 客户端 (Client) 是包含当前程序业务逻辑的类。
- 客户端接口 (Client Interface) 描述了其他类与客户端代码合作时必须遵循的协议。
- 服务 (Service) 中有一些功能类 (通常来自第三方或遗留系统)。 客户端与其接口不兼容, 因此无法直接调用其功能。
- 适配器 (Adapter) 是一个可以同时与客户端和服务交互的类: 它在实现客户端接口的同时封装了服务对象。 适配器接受客户端通过适配器接口发起的调用, 并将其转换为适用于被封装服务对象的调用。
- 客户端代码只需通过接口与适配器交互即可, 无需与具体的适配器类耦合。 因此, 你可以向程序中添加新类型的适配器而无需修改已有代码。 这在服务类的接口被更改或替换时很有用: 你无需修改客户端代码就可以创建新的适配器类。
三、类适配器
适配器模式依据实现方式分为两种:一种是对象适配器,另一种是类适配器。前面所讲述的适配器模式是对象适配器(主要说的是LogAdapter
类),这种适配器模式的实现用了类与类之间的组合关系,也就是一个类的定义中含有其他类类型的成员变量。这种关系实现了委托机制(即成员函数把功能的实现委托给了其他类的成员函数,当然需要持有一根其他类的指针,才能实现委托)。
在前面的范例中,可以理解为LogAdapter
对象包含着一个LogToFile
对象。这是一种委托机制(即成员函数把功能的实现委托给了其他类的成员函数,当然需要持有一根其他类的指针,才能实现委托)。
而对于类适配器,则是通过类与类之间的继承关系来实现接口的适配,即适配器类和适配者类之间是继承关系。我们改造上面的适配器:
class LogAdapter : public LogToDatabase, private LogToFile {
public:
LogAdapter() {
// 初始化文件日志
}
virtual void initdb() override {
// 实现数据库初始化
}
virtual void writetodb(const string& message) override {
writetofile(message); // 将消息适配为文件日志
}
virtual void readfromdb() override {
readfromfile(); // 适配从文件读取
}
virtual void closedb() override {
closefile(); // 关闭文件
}
};
在调用时:
LogToDatabase* plogdb2 = new LogAdapter();
plogdb2->initdb();
plogdb2->writetodb("向数据库中写人一条日志,实际是向日志文件中写人一条日志");
plogdb2->readfromdb();
plogdb2->closedb();
delete plogdb2;
执行起来,结果不变。
从代码中可以看到,LogAdapter
使用了多重继承,以public
(公有继承)的方式继承了LogToDatabase
, public
继承所代表的是一种is-a关系,也就是通过子类产生的对象一定也是一个父类对象(子类继承了父类的接口)。LogAdapter
还以private
(protected
也可以)的方式继承了LogToFile
类,private
继承关系就不是一种is-a关系了,而是一种组合关系。这里的private
继承就表示想通过LogToFile
类实现出LogAdapter
的意思。
一般来说,不适应类适配器。因为它不如对象适配器灵活,private
继承方式限制了LogAdapter
能调用LogToFile
的接口,而对象适配器中采用指针就灵活的多。
类适配器结构
四、总结
适配器模式在软件开发中使用得比较广泛,但并不是总是最佳选择。过多地使用适配器模式可能会导致混淆,因为从外部看调用的是 A 接口,但内部却适配成了 B 接口。这种情况在项目后期重构时通常更常见,因此在可能的情况下,重构代码可能比使用适配器更好。
然而,在软件开发中,发布新版本时常常会面临与旧版本的兼容性问题。完全抛弃旧版本并不现实,因此适配器模式可以帮助实现新旧版本的兼容。尤其在遗留代码的复用和类库迁移等方面,适配器模式发挥了重要作用。
尽管适配器模式有时让人感到无奈,仿佛是在无法修改接口的情况下才被迫使用,但在某些情况下,它实际上可以帮助实现更实质性的功能。这一点在 C++ 标准库(STL)中得到了很好的体现。
STL 包含六个主要组件:容器、算法、迭代器、函数对象(仿函数)、内存分配器和适配器。C++ 标准库中有许多适配器,主要分为容器适配器、算法适配器和迭代器适配器。适配器的作用是对现有的东西进行适当的修改,比如增加或减少某些内容,从而变成一个适配器。
- 容器适配器:
std::stack
:基于底层容器(如std::deque
或std::vector
)实现的栈(后进先出)结构。 - 算法适配器:如,
std::bind
绑定器就是一个典型的算法适配器。 - 迭代器适配器:如
reverse_iterator
(反向迭代器),其实现只是对迭代器iterator
进行了封装。
桥接模式通常会于开发前期进行设计, 使你能够将程序的各个部分独立开来以便开发。 另一方面, 适配器模式通常在已有程序中使用, 让相互不兼容的类能很好地合作。
适配器可以对已有对象的接口进行修改, 装饰模式则能在不改变对象接口的前提下强化对象功能。 此外, 装饰还支持递归组合, 适配器则无法实现。
适配器能为被封装对象提供不同的接口, 代理模式能为对象提供相同的接口, 装饰则能为对象提供加强的接口。
外观模式为现有对象定义了一个新接口, 适配器则会试图运用已有的接口。 适配器通常只封装一个对象, 外观通常会作用于整个对象子系统上。
桥接、 状态模式和策略模式 (在某种程度上包括适配器) 模式的接口非常相似。 实际上, 它们都基于组合模式——即将工作委派给其他对象, 不过也各自解决了不同的问题。 模式并不只是以特定方式组织代码的配方, 你还可以使用它们来和其他开发者讨论模式所解决的问题。