C++ 插件机制的实现原理过程及使用
Posted 特立独行的猫a
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了C++ 插件机制的实现原理过程及使用相关的知识，希望对你有一定的参考价值。
什么是插件机制
插件是你想开发一个好的系统所需要的一种好的架构方式。C++插件是 C++ 编写的动态链接共享对象。一种可复用的、灵活管理（维护、替换或增加、删除）的功能模块儿化组件。基于插件的扩展性，进而实现业务模块儿的独立和解耦，增加可维护性和可扩展性。插件使得第三方开发人员可以为系统做增值工作，也可以使其他开发人员协同开发相互配合，增加新的功能而不破坏现有的核心功能。插件能够促进将关注点分开，保证隐藏实现细节，且可以将测试独立开来，并最具有实践意义。
比如强大的Eclipse的平台实际上就是一个所有功能都由插件提供的骨架。Eclipse IDE自身（包括UI和Java开发环境）仅仅是一系列挂在核心框架上的插件。
插件机制仍需要考虑的一些问题如错误处理，数据类型，版本控制，与框架代码以及应用代码的分离等等。或许，在应用程序框架容器内，可以借助lua脚本来动态的灵活的实现业务。
为什么要用插件机制
我们为什么要用插件架构？
现代软件工程已经从原先的通用程序库逐步过渡到应用程序框架。假设一个场景，以C++开发应用程序为例，我们的架构是基于APP+DLL的传统架构，所有的功能糅杂在一起。随着系统的日益庞大，各种模块之间耦合在一起，当修改其中一个模块时，其他模块也跟着一起受到影响。假如这两个模块式不同的开发人员负责的，那么还需要事先沟通好，这样就造成了修改维护的困难。那怎么解决这个问题？插件架构是一种选择。
“编程就是构建一个一个自己的小积木， 然后用自己的小积木搭建大系统”。但是程序还是会比积木要复杂， 我们的系统必须要保证小积木能搭建出大的系统（必须能被组合），有必须能使各个积木之间的耦合降低到最小。
传统的程序结构中也是有模块的划分，但是主要有如下几个缺点：
1: c++二进制兼容问题。
2: 模块对外暴露的东西过多，使调用者要关心的东西过多。
3: 封装的模块只是作为功能的实现者封装，而不是接口的提供者。
4: 可替换性和可扩展性差。
而插件式的系统架构就是为了解决这样的问题，插件机制也很符合设计模式的六大原则（现在是七大原则），是一种不错的设计。设计模式的六大原则里提到的单一职责原则、开放封闭原则、接口隔离原则、里氏替换原则，依赖倒转原则、迪米特法则。可以说插件机制几乎满足了这六大原则里所有的条款，当然也具备了由此带来的益处，因此学习和使用插件机制很有必要。
设计模式七大原则
都是为了更好的代码重用性，可读性，可靠性，可维护性，可扩展性。
单一职责原则：
即一个类应该只负责一项职责，降低类的复杂度，免得改了一个影响另一个。提高类的可读性，可维护性，降低变更引起的风险。插件机制的各个插件模块就是一种单一职责。
开闭原则：
一个软件实体如类，模块和函数应该对扩展开放，对修改关闭。用抽象构建框架，用实现扩展细节。当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。插件机制不正好的这个原则的实现吗。
迪米特法则：
一个对象应该对其他对象保持最少的了解。类与类关系越密切，耦合度越大。
迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public 方法，不对外泄露任何信息。插件机制的实现是这一法则很好的诠释。
接口隔离原则：
客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。后面的插件实现过程可以看到，插件所提供的接口是精简和必要的最小单元。
依赖倒转原则：
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。插件机制的实现上，插件提供的接口可以看作是一种高层模块，不依赖于底层实现细节。
里氏替换原则：
所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。根据这个理解，引申含义为：子类可以扩展父类的功能，但不能改变父类原有的功能。
合成复用原则：
该原则阐述的是我们应该如何复用类。复用类我们可以通过“继承”和“合成”两种方式来实现。它最大的缺点就是增加了类之间的依赖，当父类发生改变时，其子类也会被动发生改变。介于继承存在的这些缺点，我们在复用类时，要优先考虑使用“合成”进行复用。合成复用原则的核心思想是：在编写代码时如果需要使用其它类，那么两个类之间尽量使用合成/聚合的方式，而不是使用继承。我们可以通过类之间的“合成”来达到“复用”代码的诉求。
插件机制的实现原理
大致思路是应用程序提供出接口，由其他同事分工或第三方实现这些接口，并编译出相应的动态链接库（即插件）；将所有插件放到某个特定目录，应用程序运行时会自动搜索该目录，并动态加载目录中的插件。
插件机制的实现过程
以下分享学习一下本司师傅，一位热心的技术大牛的设计插件的方式以及思路。在此表示感谢！
一、首先定义一个插件接口Iplugin.h。
这有点儿类似设计模式中的中介者模式。所有的插件模块儿之间接触，都通过这一公共的中间人交互。
#ifndef SERVICEPROJECT_IPLUGIN_H
#define SERVICEPROJECT_IPLUGIN_H
#include <QString>
#include <QStringList>
class IPlugin
public:
IPlugin() = default;
virtual ~IPlugin() = default;
IPlugin(const IPlugin&) = delete;
IPlugin& operator=(const IPlugin&) = delete;
public:
//获取支持的插件方法
virtual const QStringList& getSupportCommandList() const return supportCommandList_;
public:
virtual QString getVersionString() const = 0;
//! \\brief 获取业务名称
//! \\return
virtual QString getPluginName() const = 0;
enum pluginState_type
idle_,
starting_,
started_,
stopping_,
stopped_,
excepting_,
;
//! 获取插件的运行状态。
//! \\return
virtual pluginState_type getPluginState() const = 0;
//! 获取插件的运行状态的解释
//! \\param state
//! \\return
static QString getPluginStateMessage(const pluginState_type& state)
QString msg = "no msg.";
switch (state)
case pluginState_type::idle_:
msg = "plugin is on idle statement.";
break;
case pluginState_type::starting_:
msg = "plugin is on starting statement.";
break;
case pluginState_type::started_:
msg = "plugin is on started statement.";
break;
case pluginState_type::stopping_:
msg = "plugin is on stopping statement.";
break;
case pluginState_type::stopped_:
msg = "plugin is on stopped statement.";
break;
case pluginState_type::excepting_:
msg = "plugin is on excepting statement.";
break;
return msg;
//! \\brief 执行业务的主要接口方法
//! \\param msg 由外部程序发送的通讯协议（比如json报文）
//! \\return 错误信息
virtual std::error_code exec(const QString& msg) = 0;
//! \\brief 业务停止运行
//! \\return
virtual std::error_code stop() return ;
//! \\brief 释放动态库资源
//! \\return 错误信息
virtual std::error_code release() = 0;
protected:
QStringList supportCommandList_;
;
#endif // SERVICEPROJECT_IPLUGIN_H二、实现插件加载，注册等操作的管理类PluginManager。
遍历lib目录中的各个插件动态库,如plugin1.dll,plugin2.dll,等，完成插件的加载和注册。使用QT的QLibrary，(instance)lib->resolve("getInstance")，这里很关键，调用resolve()函数找到dll库中的getInstance函数，并强制转换为函数指针。后又强制转换为(IPlugin *)类型指针存储进QHash。
#include <QHash>
#include <QObject>
#if defined(PLUGIN_MANAGER_BUILD_SHARED)
#define PLUGIN_MANAGER_EXPORT __declspec(dllexport)
#else
#define PLUGIN_MANAGER_EXPORT __declspec(dllimport)
#endif
class IPlugin;
class QLibrary;
class PLUGIN_MANAGER_EXPORT PluginManager : public QObject
Q_OBJECT
private:
explicit PluginManager(QObject* parent = nullptr);
public:
static PluginManager* getInstance();
~PluginManager() override;
static const char* getLibraryName();
static const char* getLibraryVersion();
public:
void loadAll();
void unloadAll();
std::error_code load(const QString& name);
std::error_code unload(const QString& name);
QStringList getNames() const return plugins_.keys();
IPlugin* get(const QString& name);
private:
QHash<QString, IPlugin*> plugins_;
QHash<QString, QLibrary*> libs_;
;//......
typedef void *(*instance)();
PluginManager::PluginManager(QObject *parent) : QObject(parent)
PluginManager::~PluginManager()
unloadAll();
void PluginManager::loadAll()
QDir pluginDir(QCoreApplication::applicationDirPath() + R"(/../lib)");
QStringList filters;
filters << QString("*%1").arg(LIB_SUFFIX);
pluginDir.setNameFilters(filters);
auto entryInfoList = pluginDir.entryInfoList();
for (const auto &info : entryInfoList)
auto lib = new QLibrary(QCoreApplication::applicationDirPath() + R"(/../lib/)" + info.fileName());
if (lib->isLoaded())
LOGGING_WARN("%s is loaded.", info.fileName().toStdString().c_str());
continue;
if (lib->load())
auto func = (instance)lib->resolve("getInstance");
if (func)
auto plugin = (IPlugin *)func();
if (plugin)
auto pluginName = plugin->getPluginName();
if (plugins_.contains(pluginName))
LOGGING_WARN("%s repeated loading.", pluginName.toStdString().c_str());
lib->unload();
lib->deleteLater();
lib = nullptr;
continue;
plugins_.insert(pluginName, plugin);
libs_.insert(pluginName, lib);
LOGGING_DEBUG("%s version: %s", plugin->getPluginName().toStdString().c_str(),
plugin->getVersionString().toStdString().c_str());
else
LOGGING_ERROR("%s object create failed.", info.fileName().toStdString().c_str());
lib->unload();
lib->deleteLater();
lib = nullptr;
else
LOGGING_ERROR("%s cannot find symbol.", info.fileName().toStdString().c_str());
lib->unload();
lib->deleteLater();
lib = nullptr;
else
LOGGING_ERROR("%s load failed. error message: %s", info.fileName().toStdString().c_str(),
lib->errorString().toStdString().c_str());
lib->deleteLater();
lib = nullptr;
void PluginManager::unloadAll()
for (auto &item : plugins_)
item->release();
for (auto &item : libs_)
item->unload();
item->deleteLater();
item = nullptr;
plugins_.clear();
libs_.clear();
......
IPlugin *PluginManager::get(const QString &name)
if (plugins_.contains(name))
return plugins_.value(name);
LOGGING_ERROR("%s is not found.", name.toStdString().c_str());
return nullptr;
PluginManager *PluginManager::getInstance()
static PluginManager w;
return &w;
const char *PluginManager::getLibraryName()
return PROJECT_NAME;
const char *PluginManager::getLibraryVersion()
return PROJECT_VERSION;
三、插件模块的实现
各个插件模块对外提供一唯一的入口函数getInstance()。
注意：该函数必须为 extern "C"声明的。why?
为什么要这么做呢？原因是C++的编译器会对程序中符号进行修饰，这个过程在编译器中叫符号修饰（Name Decoration）或者符号改编（Name Mangling）。如果不改为c的方式，那么动态库resolve这种查找入口方式，会找不到句柄handle入口。
在这个getInstance函数内部，可以实例化具体的类对象（前提这类对象实现了IPlugin接口）。
//myplugin1dll.h
extern "C" __declspec(dllexport) void *getInstance();
//myplugin1dll.cpp
void* getInstance()
static MyPlugin1 w;
return (void*)&w;
//MyPlugin1.h
class MyPlugin1: public IPlugin
public:
MyPlugin1();
~MyPlugin1() override;
public:
QString getVersionString() const override;
//! \\brief 获取业务名称
//! \\return
QString getPluginName() const override;
//! 获取插件的运行状态。
//! \\return
pluginState_type getPluginState() const override;
//! \\brief 执行业务
//! \\param msg 由外部程序发送的通讯协议
//! \\return 错误信息
std::error_code exec(const QString &msg) override;
//! \\brief 业务停止运行
//! \\return
std::error_code stop() override;
//! \\brief 释放动态库资源
//! \\return 错误信息
std::error_code release() override;
;
//MyPlugin1.cpp
......
#define MY_PLUGIN_NAME "myplugin1"
MyPlugin1::MyPlugin1()
//关键，这里追定了本插件的插件名，插件管理类对象PluginManager会根据这个找到自己
supportCommandList_.push_back(MY_PLUGIN_NAME);
MyPlugin1::~MyPlugin1()
QString MyPlugin1::getVersionString() const
return PROJECT_VERSION;
QString MyPlugin1::getPluginName() const
return PROJECT_NAME;
IPlugin::pluginState_type MyPlugin1::getPluginState() const
return IPlugin::starting_;
std::error_code MyPlugin1::exec(const QString& msge)
//业务功能实现......
举例插件机制的使用
经过前面三步，准备工作做好了。如何使用看看效果呢？
我们写一个测试的do_pluginWork(const QString& msg, const QString& cmd)。
其中的cmd内容指定插件名称。
实现过程为遍历PluginManager中管理的所有插件名，找到对应的并传递调用参数msg。
假如实现了两个插件plugin1.dll和plugin2.dll ,do_pluginWork("hello","plugin1"),则会调用plugin1中的exec函数功能。
//......
do_pluginWork(const QString& msg, const QString& cmd)
auto allPluginNames = PluginManager::getInstance()->getNames();
for (const auto& name : allPluginNames)
auto pluginPtr = PluginManager::getInstance()->get(name);
if (pluginPtr)
if (pluginPtr->getSupportCommandList().contains(cmd))
auto errorCode = pluginPtr->exec(msg);
if (errorCode.value())
LOGGING_ERROR("[%s] result message: %s", pluginPtr->getPluginName().toStdString().c_str(),
errorCode.message().c_str());
LOGGING_DEBUG("%s is executed.", cmd.toStdString().c_str());
return;
LOGGING_ERROR("cannot found match command.");
最后，插件机制是不是挺不错的，愉快的使用吧。
引用：
利用C++实现插件系统_猫咪的晴天的博客-CSDN博客_c++ 插件系统
C++ 插件系统_qq_32250025的博客-CSDN博客_c++ 插件
C++插件架构浅谈与初步实现_臣有一事不知当不当讲的博客-CSDN博客_c++插件
构建自己的C/C++插件开发框架_加油努力4ever的博客-CSDN博客_c++插件框架
C/C++：构建你自己的插件框架_石头的博客-CSDN博客_c 插件框架
软件设计七大原则，看完这一篇就够了_凹凸曼蓝博one的博客-CSDN博客_合成复用原则
C++实现插件化开发_gnr_123的博客-CSDN博客_c++ 插件化
C++插件架构浅谈与初步实现_周旭光的博客-CSDN博客_c++插件框架
以上是关于C++ 插件机制的实现原理过程及使用的主要内容，如果未能解决你的问题，请参考以下文章