插件是你想开发一个好的系统所需要的一种好的架构方式。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
#include
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
#include
#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 plugins_;
QHash 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++插件框架