【问题标题】:C/C++ Plugin API design dilemmaC/C++ Plugin API 设计困境
【发布时间】:2013-04-02 09:54:36
【问题描述】:

我正在为一个包含 3 个组件的解决方案设计 C/C++ 插件架构:

  1. 客户端级别
  2. 核心级别
  3. 可视化级别

所有这些级别都有与另一端相应插件对话的插件(即:客户端,磁盘插件与核心磁盘插件对话,可能还有可视化磁盘插件,但不与核心CPU插件对话)

现在,我想让插件的创建尽可能简单,所以我想出了以下内容:插件在共享库中实现并根据请求加载,并且有一组预定义的函数,例如加载, unload, name, etc... 组件加载插件共享库,查找这些函数,完成工作,卸载插件。

现在,有一个头文件,比如:

plugin_client.h:

/***************************************************************************
 *             Methods that are exposed in a client side plugin            * 
 ***************************************************************************/
PLUGIN_LOAD_STATUS load();
PLUGIN_UNLOAD_STATUS unload(PLUGIN_UNLOAD_REQUEST reason);
const char* name();
void do_work();

这让插件开发者清楚,他需要实现上述功能才能使插件能够集成到系统的客户端组件中。

这里开始进退两难:对于核心组件插件,也应该有一个非常相似(几乎相同)的头文件,可视化部分也是如此。问题来了:

我应该如何处理这种情况?我想到了 2 个解决方案:

  1. 不同组件的所有插件的一个通用头文件,即:plugin.h,所有可以实现的功能都在里面,用cmets,这个方法应该在客户端实现,在核心,在可视化组件中。这样做的缺点是所有内容都集中在一个地方,并且许多不必要的东西都会被不感兴趣的各方看到。
  2. 每个插件的头文件,所以:plugin_client.hplugin_core.hplugin_vis.h和插件开发人员包括他想要的。这些插件有一个特殊的功能:int plugin_type();,如果这是一个客户端、核心或可视化插件,它会返回。这样做的缺点是信息重复。

如果您对如何优雅地解决这个困境有任何想法,请告诉我?

谢谢,f.

【问题讨论】:

    标签: c++ c plugins


    【解决方案1】:

    实际上不必重复信息。特定类型的标头如何包含基本标头,如下所示:

    plugin_base.h

    /***************************************************************************
     *             Methods that are exposed in a client side plugin            * 
     ***************************************************************************/
    PLUGIN_LOAD_STATUS load();
    PLUGIN_UNLOAD_STATUS unload(PLUGIN_UNLOAD_REQUEST reason);
    const char* name();
    void do_work();
    int plugin_type();
    

    plugin_client.h:

    #include "plugin_base.h"
    void client_only_function();
    

    其他插件类型完全相同。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多