关于程序插件机制的困惑

大板牙花生 2020-04-08 10:58:49
许多软件的构成是插件机制比如eclipse像这样的软件,动态加载插件也能够理解,反射机制也能够理解,只是不明白这些插件是如何能够在运行时候得到识别反馈的,比如加载插件后如何跟原有的功能进行通信?是通过回调机制吗?消息机制,有没有代码演示一下呢?
...全文
318 点赞 收藏 3
写回复
3 条回复
大板牙花生 2020年04月26日
还有一个疑问,如果UI也以插件的形式设计,在某个功能窗体上实现新的子功能窗体,这样是不是需要提前确定了功能窗体的接口规范了,如果子功能窗体不知道的目标功能窗体,该如何去设计这样的规范?
回复 点赞
大板牙花生 2020年04月10日
引用 1 楼 _mervyn 的回复:
每个支持所谓“插件”功能的程序,具体实现肯定都不会是一样的,这个没有统一标准。自己想怎么实现就怎么实现。
比如你自己想实现一套插件机制可以这样设计:
1、规定插件以怎样的形式存在,dll or exe?
2、规定插件必须实现一系列事先就定义好的接口,你不实现,我就不理你
3、这一系列接口你自己可以随意定义,这就很灵活了,你想要插件能做到什么程度,就定义到什么程度,只要最后给出文档,让插件开发者可以按文档开发就行。当然你的接口设计的好不好那就另说了。
4、定义插件安装机制,简单点的话,就一股脑放到你主程序的某个目录里,程序启动的时候扫描所有,把所有符合自己标准的(实现了我规定的所有接口)插件加载进来就好。当然,你也可以让用户自己在界面上选择需要加载哪些插件或者在程序运行时动态加载,如何识别还是一个道理。

关键的就是你如何定义接口了。以dll形式的插件为例,举个简单的例子:
插件初始化:

/** @fn typedef int (MODULE_API *Module_Init)()
* @brief 初始化模块;
* @param szPath [in] 模块目录;
* @return 成功返回0,否则返回其他值;
*/
typedef int (MODULE_API *Module_Init)(const char* szPath);


插件反初始化:
/** @fn typedef int (MODULE_API *Module_Uninit)()
* @brief 反初始化模块;
* @param void
* @return 成功返回0,否则返回其他值;
*/
typedef int (MODULE_API *Module_Uninit)();


其他需要实现的接口可以统一由一个Module_Proc定义.
功能接口Module_Proc的定义:

/** @brief 功能接口调用完成通知;
* @param error [in] 错误码;
* @param data [in] 数据结果;
* @param size [in] 数据长度;
* @param usr [in] 用户数据;
* @return 成功返回0,失败返回其他值;
*/
typedef int (SRPC_API *COMPLETIONPROC)(unsigned int error,const void* data,unsigned int size,void* usr);

//************************************
// Method: Module_Proc
// Brief: 功能过程;
// Returns: int
// Parameter: void* data_in 数据(参数);
// Parameter: unsigned int size_in 数据大小;
// Parameter: COMPLETIONPROC proc 完成回调;
// Parameter: void* usr 框架内部数据,需要用户传给proc;
//note:
// 注意:一般情况下,proc 和 usr 只能在该函数之内使用以同步返回结果!;除非用户返回100;
// 这意味着,如果该函数返回了100,框架内部结构usr的生存权将转移给用户,其不会被释放直到用户调用了proc;
//************************************
typedef int (MODULE_API *Module_Proc)( const void* data_in, unsigned int size_in, COMPLETIONPROC proc,void* usr);


然后,插件库内部就可以定义 Module_Proc 形式的功能函数地址了。功能可以有很多个,一般来讲,我们需要插件提供的功能都是接收我们主程序的通知,比如:程序启动通知,程序退出通知,用户干了啥啥啥通知,等等等等。我们可以只定义一个接口,让插件实现,以便我们一次性去获取插件提供的所有功能,那么可以这样定义一个Module_GetAllExportProc接口:

/** @struct _PROCINFO
* @brief 过程信息表;用key表示功能的名称字符串,pAddr为功能函数的地址
* 比如key可以是“onProgamStartEnd”表示我们的主程序启动完毕了,如果插件在这个时候想做什么,就去实现这个接口。
* 比如key可以是“onReportStatus”表示我们的主程序想要获取插件的运行状态,插件如果想报告运行状态,就去实现这个接口。
*/
typedef struct _PROCINFO
{
char szKey[MODULE_KEY_MAXLENTH];
Module_Proc pAddr;
}PROCINFO;

/** @fn typedef int (MODULE_API *Module_RegisterProc)(const PROCINFO* procedures,unsigned int count,void* usr);
* @brief 注册过程信息;
* @param const PROCINFO* [in] 过程信息表;
* @param unsigned int [in] 注册数量;
* @param void* [in] 用户数据;
* @return 成功返回0,否则返回其他值;
*/
typedef int (MODULE_API *Module_RegisterProc)(const PROCINFO* procedures,unsigned int count,void* usr);

/** @fn typedef int (MODULE_API *Module_GetAllExportProc)(Module_FnInfo fnReg);
* @brief 获取所有导出的过程地址;
* @param Module_RegisterProc [in] 过程注册地址;
* @param void* [in] 用户数据;
* @return 成功返回0,否则返回其他值;
*/
typedef int (MODULE_API *Module_GetAllExportProc)(Module_RegisterProc regAddr,void* usr);

Module_GetAllExportProc 接收两个参数,都是由我们的主程序在加载后,来调用传入的,一个参数是Module_RegisterProc函数地址,使插件开发者可以调用它来导出自己所有的功能函数,另一个参数usr是Module_RegisterProc所需要的参数。

那么以插件实现者的角度,简单给一个实现Module_GetAllExportProc形式的例子:
假设,我们的插件有两个功能要实现,分别是onProgamStartEnd接收程序启动完毕通知、onReportStatus报告插件运行状态:

int MODULE_API Plugin_OnProgamStartEnd(const void* data_in, unsigned int size_in, COMPLETIONPROC fn,void* usr)
{
//这里就可以做一些程序启动完毕时要做的处理
//...
return 0;
}


int MODULE_API Plugin_OnReportStatus( const void* data_in, unsigned int size_in, COMPLETIONPROC fn,void* usr)
{
//使用fn向我们主程序报告运行状态
if (fn)
{
fn(0,"这里可以是任何内容表示当前的运行状态,比如用json", 内容长度, usr);
}
return 0;
}


导出这两个功能地址,以便主程序调用

int MODULE_API GetAllExportProcName(Module_RegisterProc regAddr,void* usr)
{
if(regAddr)
{
const PROCINFO proc_info_t[] =
{
{"onProgamStartEnd", &Plugin_OnProgamStartEnd},
{"onReportStatus", &Plugin_OnReportStatus},
{NULL,NULL}
};
unsigned int count = sizeof(proc_info_t) / sizeof(PROCINFO);
return regAddr(proc_info_t,count,usr);
}
return -1;
}


到目前为止,我们定义了1、插件的初始化接口,2、插件的反初始化接口,3、插件的所有功能获取接口。同时给了接口3的实现例子。
插件确实可以被动接收我们主程序的通知或者调用了,那么插件如何主动调用主程序的功能呢?
那其实也可以通过类似Module_GetAllExportProc的定义方式,来获取主程序的所有功能,只不过这一次,Module_GetAllExportProc实现在我们的主程序中,并将它的地址通过某种方式告诉插件,让插件去获取主程序的所有功能地址。
这个“某种方式”可以是:
a、在Module_Init中新加一个参数接收
b、新定义的一个接口要求插件实现
c、直接让插件在上面例子的GetAllExportProcName函数中导出一个叫onProgamAllProcs的功能来接收主程序的所有功能名及功能函数地址。

这里我们先以最简单的a方法重新定义一下初始化函数:

/** @fn typedef int (MODULE_API *Module_Init)()
* @brief 初始化模块;
* @param szPath [in] 模块目录;
* @param getAllProgamProcs [in] 主程序所有功能获取接口;
* @return 成功返回0,否则返回其他值;
*/
typedef int (MODULE_API *Module_Init)(const char* szPath , Module_GetAllExportProc getAllProgamProcs);

实现之:
int MODULE_API Plugin_Init(const char* szPath, Module_GetAllExportProc getAllProgamProcs)
{
// do something Init first.....
//...

//获取主程序的所有功能
if(getAllProgamProcs)
{
getAllProgamProcs(®isterProcCallback, NULL);
}
return 0;
}

int MODULE_API RegisterProcCallback(const PROCINFO* procedures,unsigned int count,void* usr)
{
for (unsigned int i = 0; i < count; i++)
{
if (procedures[i].pAddr)
{
//处理,比如将主程序的所有功能及对应地址保存起来,供后续调用...
//addFnInterface(procedures[i].szKey, procedures[i].pAddr);
//...
//比如主程序有个功能是打开一个文件,那我们把这个功能名叫做 ProgamOpenFile
//这里就会有一个procedures[i].szKey 等于"ProgamOpenFile",其功能函数地址就是procedures[i].pAddr
//当插件想要使用这个功能就调用它就完事了: procedures[i].pAddr(...);
//当然主程序有哪些功能,叫什么名字,接受的参数格式什么样的,那就要我们写好的文档供插件开发者查阅了。
}
}
return 0;
}


如果用b方法,重新定义一个接口要求插件实现,也是一样的,就不演示了。

如果用c方法也是可以的,也是多实现一个插件功能用来接收主程序的所有功能通知。

int MODULE_API Plugin_OnProgamAllProcs(const void* data_in, unsigned int size_in, COMPLETIONPROC fn,void* usr)
{
//这里data_in内容其实可以任意定义,如果是dll插件,简单点可以直接将内容定义成Module_GetAllExportProc函数指针,那么size_in就是指针长度

// Module_GetAllExportProc* pGetAllProgamProcs = (Module_GetAllExportProc*)data_in;
// 等同于 memcpy(pGetAllProgamProcs, data_in, sizeof(Module_GetAllExportProc));

// 之后就和上面Plugin_Init例子里一样了:
// if(*pGetAllProgamProcs)
// {
// (*pGetAllProgamProcs)(®isterProcCallback, NULL);
// }
//...

//或者为了更通用,以适用于exe插件,data_in可以是json,包含所有主程序的功能名。这里就不作展开了。
return 0;
}
//修改GetAllExportProcName 增加onProgamAllProcs通知接收
int MODULE_API GetAllExportProcName(Module_RegisterProc regAddr,void* usr)
{
if(regAddr)
{
const PROCINFO proc_info_t[] =
{
{"onProgamAllProcs", &Plugin_OnProgamAllProcs},
{"onProgamStartEnd", &Plugin_OnProgamStartEnd},
{"onReportStatus", &Plugin_OnReportStatus},
{NULL,NULL}
};
unsigned int count = sizeof(proc_info_t) / sizeof(PROCINFO);
return regAddr(proc_info_t,count,usr);
}
return -1;
}


另外,我们还可以把定义的3个接口(Module_Init,Module_Uninit,Module_GetAllExportProc)合并成一个Module_GetMEAT,这样我们加载插件后,只要检查这一个接口有没有实现就可以判断它是否为合法插件了。具体方法原理还是一样的,可以参考Module_GetAllExportProc

//----------- 模块库必须导出的接口; ------------//
/*
*
* 模块内部必须实现 _MODULE_EXPORT_ADDR_T 定义的一系列接口;
* 框架通过这些接口与模块进行交互;
*
* 模块库必须导出下面声明的接口,框架通过该接口识别动态库是否为合法模块;
* MODULE_EXTERN int MODULE_API MODULE_GetMEAT(Module_ExportAddr eFunc,void* usr)
*
*
*/

/** @struct _MODULE_EXPORT_ADDR_T
* @brief 模块与框架交互的接口地址表;
*/
typedef struct _MODULE_EXPORT_ADDR_T
{
Module_Init Init; ///< 模块初始化接口地址;
Module_Uninit Uninit; ///< 模块反初始化接口地址;
Module_GetAllExportProc GetAllProc; ///< 获取所有暴露过程接口地址;
}MEAT;

/** @fn typedef int (MODULE_API *Module_ExportAddr)(MEAT* pMEAT);
* @brief 导出接口地址表;
* @param MEAT* [in] 地址表;
* @param void* [in] 用户数据;
* @return 成功返回0,否则返回其他值;
*/
typedef int (MODULE_API *Module_ExportAddr)(const MEAT* pMEAT,void* usr);

/** @fn typedef int (MODULE_API *Module_GetMEAT)();
* @brief 获取模块与框架交互的接口地址表;
* @param Module_ExportAddr [in] 导出接口地址表的函数地址;
* @param void* [in] 用户数据;
* @return 成功返回0,否则返回其他值;
*/
typedef int (*Module_GetMEAT)(Module_ExportAddr eFunc,void* usr);


这样,插件只要实现这个接口,并导出这唯一的一个接口就可以了:

MODULE_EXTERN int Plugin_GetMEAT(Module_ExportAddr eFunc,void* usr)
{
if(eFunc)
{
const MEAT export_addr_t = {
Plugin_Init,
Plugin_Uninit,
GetAllExportProcName
};
return eFunc(&export_addr_t,usr);
}
return -1;
}

相关宏:

#if (defined(_WIN32) || defined(_WIN64))
# define MODULE_EXTERN extern "C" __declspec(dllexport)
# define MODULE_API __stdcall
#elif defined(__linux__)
# define MODULE_EXTERN extern "C"
# define MODULE_API
#else
# define MODULE_EXTERN
# define MODULE_API
#endif


以上,其实就是本人以前设计的一个模块化开发方案的一部分。不光支持dll、so形式的动态库模块,也可以是exe这样的可执行模块。不仅适用于是同进程内的通信,也适用于不同进程甚至不同主机间的通信。这也解释了为什么我将“功能接口”形式统一成了这样的固定形式,又将它与一个字符串名字关联起来。就是为了方便不同进程间的通信。
那么将它用在“插件开发”上其实也是绰绰有余的。

总之,插件机制的实现可以有很多种,我举的这个例子只是其中一种,至于它怎么样,就见仁见智了。仅供参考。
对大师的膜拜,是我等凡人的荣幸。这里面体现了很多思维是我这些渣渣所学习不到的。请教一下大神,除了大量的代码经验积累之外,有没有权威的代码库或者是书籍推荐一下,为写这些良好架构设计的软件提供一些思路指引?
回复 点赞
_mervyn 2020年04月09日
每个支持所谓“插件”功能的程序,具体实现肯定都不会是一样的,这个没有统一标准。自己想怎么实现就怎么实现。 比如你自己想实现一套插件机制可以这样设计: 1、规定插件以怎样的形式存在,dll or exe? 2、规定插件必须实现一系列事先就定义好的接口,你不实现,我就不理你 3、这一系列接口你自己可以随意定义,这就很灵活了,你想要插件能做到什么程度,就定义到什么程度,只要最后给出文档,让插件开发者可以按文档开发就行。当然你的接口设计的好不好那就另说了。 4、定义插件安装机制,简单点的话,就一股脑放到你主程序的某个目录里,程序启动的时候扫描所有,把所有符合自己标准的(实现了我规定的所有接口)插件加载进来就好。当然,你也可以让用户自己在界面上选择需要加载哪些插件或者在程序运行时动态加载,如何识别还是一个道理。 关键的就是你如何定义接口了。以dll形式的插件为例,举个简单的例子: 插件初始化:

/** @fn typedef int (MODULE_API *Module_Init)()
 *  @brief 初始化模块;
 *  @param szPath [in] 模块目录;
 *  @return 成功返回0,否则返回其他值;
 */
typedef int (MODULE_API *Module_Init)(const char* szPath);
插件反初始化:
/** @fn typedef int (MODULE_API *Module_Uninit)()
 *  @brief 反初始化模块;
 *  @param void
 *  @return 成功返回0,否则返回其他值;
 */
typedef int (MODULE_API *Module_Uninit)();
其他需要实现的接口可以统一由一个Module_Proc定义. 功能接口Module_Proc的定义:

/** @brief 功能接口调用完成通知;
 *  @param error [in] 错误码;
 *  @param data [in] 数据结果;
 *  @param size [in]  数据长度;
 *  @param usr [in]  用户数据;
 *  @return 成功返回0,失败返回其他值;
 */
typedef int (SRPC_API *COMPLETIONPROC)(unsigned int error,const void* data,unsigned int size,void* usr);

//************************************
// Method:    Module_Proc
// Brief:  	  功能过程;
// Returns:   int		
// Parameter: void* data_in				数据(参数);
// Parameter: unsigned int size_in		数据大小;
// Parameter: COMPLETIONPROC proc		完成回调;
// Parameter: void* usr					框架内部数据,需要用户传给proc;
//note:
// 注意:一般情况下,proc 和 usr 只能在该函数之内使用以同步返回结果!;除非用户返回100;
// 这意味着,如果该函数返回了100,框架内部结构usr的生存权将转移给用户,其不会被释放直到用户调用了proc;
//************************************
typedef int (MODULE_API *Module_Proc)( const void* data_in, unsigned int size_in, COMPLETIONPROC proc,void* usr);
然后,插件库内部就可以定义 Module_Proc 形式的功能函数地址了。功能可以有很多个,一般来讲,我们需要插件提供的功能都是接收我们主程序的通知,比如:程序启动通知,程序退出通知,用户干了啥啥啥通知,等等等等。我们可以只定义一个接口,让插件实现,以便我们一次性去获取插件提供的所有功能,那么可以这样定义一个Module_GetAllExportProc接口:

/** @struct _PROCINFO
 *  @brief 过程信息表;用key表示功能的名称字符串,pAddr为功能函数的地址
 * 比如key可以是“onProgamStartEnd”表示我们的主程序启动完毕了,如果插件在这个时候想做什么,就去实现这个接口。
 * 比如key可以是“onReportStatus”表示我们的主程序想要获取插件的运行状态,插件如果想报告运行状态,就去实现这个接口。
 */
typedef struct _PROCINFO
{
	char			szKey[MODULE_KEY_MAXLENTH];
	Module_Proc		pAddr;
}PROCINFO;

/** @fn typedef int (MODULE_API *Module_RegisterProc)(const PROCINFO* procedures,unsigned int count,void* usr);
 *  @brief 注册过程信息;
 *  @param const PROCINFO* [in]		过程信息表;
 *  @param unsigned int [in]		注册数量;
 *  @param void* [in]				用户数据;
 *  @return 成功返回0,否则返回其他值;
 */
typedef int (MODULE_API *Module_RegisterProc)(const PROCINFO* procedures,unsigned int count,void* usr);

/** @fn typedef int (MODULE_API *Module_GetAllExportProc)(Module_FnInfo fnReg);
 *  @brief 获取所有导出的过程地址;
 *  @param Module_RegisterProc [in] 过程注册地址;
 *  @param void* [in]				用户数据;
 *  @return 成功返回0,否则返回其他值;
 */
typedef int (MODULE_API *Module_GetAllExportProc)(Module_RegisterProc regAddr,void* usr);
Module_GetAllExportProc 接收两个参数,都是由我们的主程序在加载后,来调用传入的,一个参数是Module_RegisterProc函数地址,使插件开发者可以调用它来导出自己所有的功能函数,另一个参数usr是Module_RegisterProc所需要的参数。 那么以插件实现者的角度,简单给一个实现Module_GetAllExportProc形式的例子: 假设,我们的插件有两个功能要实现,分别是onProgamStartEnd接收程序启动完毕通知、onReportStatus报告插件运行状态:

int MODULE_API Plugin_OnProgamStartEnd(const void* data_in, unsigned int size_in, COMPLETIONPROC fn,void* usr)
{
	//这里就可以做一些程序启动完毕时要做的处理
	//...
	return 0;
}

int MODULE_API Plugin_OnReportStatus( const void* data_in, unsigned int size_in, COMPLETIONPROC fn,void* usr)
{      
	//使用fn向我们主程序报告运行状态
	if (fn)
	{
		fn(0,"这里可以是任何内容表示当前的运行状态,比如用json",  内容长度,  usr);
	}
	return 0;
}
导出这两个功能地址,以便主程序调用

int MODULE_API GetAllExportProcName(Module_RegisterProc regAddr,void* usr) 
{ 
	if(regAddr) 
	{
		const PROCINFO proc_info_t[] = 
		{
			{"onProgamStartEnd", &Plugin_OnProgamStartEnd},
			{"onReportStatus", &Plugin_OnReportStatus},
			{NULL,NULL} 
		};
		unsigned int count = sizeof(proc_info_t) / sizeof(PROCINFO);
		return regAddr(proc_info_t,count,usr);
	}
	return -1;
}
到目前为止,我们定义了1、插件的初始化接口,2、插件的反初始化接口,3、插件的所有功能获取接口。同时给了接口3的实现例子。 插件确实可以被动接收我们主程序的通知或者调用了,那么插件如何主动调用主程序的功能呢? 那其实也可以通过类似Module_GetAllExportProc的定义方式,来获取主程序的所有功能,只不过这一次,Module_GetAllExportProc实现在我们的主程序中,并将它的地址通过某种方式告诉插件,让插件去获取主程序的所有功能地址。 这个“某种方式”可以是: a、在Module_Init中新加一个参数接收 b、新定义的一个接口要求插件实现 c、直接让插件在上面例子的GetAllExportProcName函数中导出一个叫onProgamAllProcs的功能来接收主程序的所有功能名及功能函数地址。 这里我们先以最简单的a方法重新定义一下初始化函数:

/** @fn typedef int (MODULE_API *Module_Init)()
 *  @brief 初始化模块;
 *  @param szPath [in] 模块目录;
 *  @param getAllProgamProcs [in] 主程序所有功能获取接口;
 *  @return 成功返回0,否则返回其他值;
 */
typedef int (MODULE_API *Module_Init)(const char* szPath , Module_GetAllExportProc getAllProgamProcs);
实现之:
int MODULE_API Plugin_Init(const char* szPath, Module_GetAllExportProc getAllProgamProcs)
{
	// do something Init first.....
	//...
	
	//获取主程序的所有功能
	if(getAllProgamProcs)
	{
		getAllProgamProcs(®isterProcCallback, NULL);
	}
	return 0;
}
int MODULE_API RegisterProcCallback(const PROCINFO* procedures,unsigned int count,void* usr)
{
	for (unsigned int i = 0; i < count; i++)
	{
		if (procedures[i].pAddr)
		{
			//处理,比如将主程序的所有功能及对应地址保存起来,供后续调用...
			//addFnInterface(procedures[i].szKey, procedures[i].pAddr);
			//...
			//比如主程序有个功能是打开一个文件,那我们把这个功能名叫做 ProgamOpenFile
			//这里就会有一个procedures[i].szKey 等于"ProgamOpenFile",其功能函数地址就是procedures[i].pAddr
			//当插件想要使用这个功能就调用它就完事了: procedures[i].pAddr(...);
			//当然主程序有哪些功能,叫什么名字,接受的参数格式什么样的,那就要我们写好的文档供插件开发者查阅了。
		}			
	}
	return 0;
}
如果用b方法,重新定义一个接口要求插件实现,也是一样的,就不演示了。 如果用c方法也是可以的,也是多实现一个插件功能用来接收主程序的所有功能通知。

int MODULE_API Plugin_OnProgamAllProcs(const void* data_in, unsigned int size_in, COMPLETIONPROC fn,void* usr)
{
	//这里data_in内容其实可以任意定义,如果是dll插件,简单点可以直接将内容定义成Module_GetAllExportProc函数指针,那么size_in就是指针长度
	
	// Module_GetAllExportProc* pGetAllProgamProcs = (Module_GetAllExportProc*)data_in;
	// 等同于 memcpy(pGetAllProgamProcs, data_in, sizeof(Module_GetAllExportProc));
	
	// 之后就和上面Plugin_Init例子里一样了:
	// if(*pGetAllProgamProcs)
	// {
	//	 (*pGetAllProgamProcs)(®isterProcCallback, NULL);
	// }
	//...
	
	//或者为了更通用,以适用于exe插件,data_in可以是json,包含所有主程序的功能名。这里就不作展开了。
	return 0;
}
//修改GetAllExportProcName 增加onProgamAllProcs通知接收
int MODULE_API GetAllExportProcName(Module_RegisterProc regAddr,void* usr) 
{ 
	if(regAddr) 
	{
		const PROCINFO proc_info_t[] = 
		{
			{"onProgamAllProcs", &Plugin_OnProgamAllProcs},
			{"onProgamStartEnd", &Plugin_OnProgamStartEnd},
			{"onReportStatus", &Plugin_OnReportStatus},
			{NULL,NULL} 
		};
		unsigned int count = sizeof(proc_info_t) / sizeof(PROCINFO);
		return regAddr(proc_info_t,count,usr);
	}
	return -1;
}
另外,我们还可以把定义的3个接口(Module_Init,Module_Uninit,Module_GetAllExportProc)合并成一个Module_GetMEAT,这样我们加载插件后,只要检查这一个接口有没有实现就可以判断它是否为合法插件了。具体方法原理还是一样的,可以参考Module_GetAllExportProc

//----------- 模块库必须导出的接口; ------------//
/*
 *
 * 模块内部必须实现 _MODULE_EXPORT_ADDR_T 定义的一系列接口;
 * 框架通过这些接口与模块进行交互;
 *
 * 模块库必须导出下面声明的接口,框架通过该接口识别动态库是否为合法模块;
 * MODULE_EXTERN int MODULE_API MODULE_GetMEAT(Module_ExportAddr eFunc,void* usr)
 *
 *
 */

/** @struct _MODULE_EXPORT_ADDR_T
 *  @brief 模块与框架交互的接口地址表;
 */
typedef struct _MODULE_EXPORT_ADDR_T
{
    Module_Init					Init;			///< 模块初始化接口地址;
    Module_Uninit				Uninit;			///< 模块反初始化接口地址;
	Module_GetAllExportProc		GetAllProc;		///< 获取所有暴露过程接口地址;
}MEAT;

/** @fn typedef int (MODULE_API *Module_ExportAddr)(MEAT* pMEAT);
 *  @brief 导出接口地址表;
 *  @param MEAT* [in]  地址表;
 *  @param void* [in]  用户数据;
 *  @return 成功返回0,否则返回其他值;
 */
typedef int (MODULE_API *Module_ExportAddr)(const MEAT* pMEAT,void* usr);

/** @fn typedef int (MODULE_API *Module_GetMEAT)();
 *  @brief 获取模块与框架交互的接口地址表;
 *  @param Module_ExportAddr [in]  导出接口地址表的函数地址;
 *  @param void* [in]  用户数据;
 *  @return 成功返回0,否则返回其他值;
 */
typedef int (*Module_GetMEAT)(Module_ExportAddr eFunc,void* usr);
这样,插件只要实现这个接口,并导出这唯一的一个接口就可以了:

MODULE_EXTERN int Plugin_GetMEAT(Module_ExportAddr eFunc,void* usr)
{ 
	if(eFunc) 
	{
		const MEAT export_addr_t = { 
			Plugin_Init, 
			Plugin_Uninit, 
			GetAllExportProcName 
		}; 
		return eFunc(&export_addr_t,usr);
	}
    return -1; 
}
相关宏:

#if (defined(_WIN32) || defined(_WIN64))
#  define MODULE_EXTERN extern "C" __declspec(dllexport)
#  define MODULE_API __stdcall
#elif defined(__linux__)
#  define MODULE_EXTERN extern "C"
#  define MODULE_API
#else
#  define MODULE_EXTERN
#  define MODULE_API
#endif
以上,其实就是本人以前设计的一个模块化开发方案的一部分。不光支持dll、so形式的动态库模块,也可以是exe这样的可执行模块。不仅适用于是同进程内的通信,也适用于不同进程甚至不同主机间的通信。这也解释了为什么我将“功能接口”形式统一成了这样的固定形式,又将它与一个字符串名字关联起来。就是为了方便不同进程间的通信。 那么将它用在“插件开发”上其实也是绰绰有余的。 总之,插件机制的实现可以有很多种,我举的这个例子只是其中一种,至于它怎么样,就见仁见智了。仅供参考。
回复 点赞
发动态
发帖子
模式及实现
创建于2007-09-28

4547

社区成员

4178

社区内容

C/C++ 模式及实现
社区公告
暂无公告