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进行了封装。

桥接模式通常会于开发前期进行设计，使你能够将程序的各个部分独立开来以便开发。另一方面，适配器模式通常在已有程序中使用，让相互不兼容的类能很好地合作。

适配器可以对已有对象的接口进行修改，装饰模式则能在不改变对象接口的前提下强化对象功能。此外，装饰还支持递归组合，适配器则无法实现。

适配器能为被封装对象提供不同的接口，代理模式能为对象提供相同的接口，装饰则能为对象提供加强的接口。

外观模式为现有对象定义了一个新接口，适配器则会试图运用已有的接口。适配器通常只封装一个对象，外观通常会作用于整个对象子系统上。

桥接、状态模式和策略模式（在某种程度上包括适配器）模式的接口非常相似。实际上，它们都基于组合模式——即将工作委派给其他对象，不过也各自解决了不同的问题。模式并不只是以特定方式组织代码的配方，你还可以使用它们来和其他开发者讨论模式所解决的问题。