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的意思。