插件/运行时扩展架构

发布于 2024-08-01 22:48:46 字数 82 浏览 0 评论 0原文

对于语言来说,通过用户给定的模块/库/代码执行插件或扩展运行时代码的常见方法是什么?? 我正在考虑 C/C++,但其他语言如何做到这一点也可能适用。

For languages what are some common ways of doing plugins or extending runtime code via user given modules/libraries/code...?? I was thinking of C/C++ but how other languages do this may be applicable as well.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

失与倦" 2024-08-08 22:48:46

一种方法是将模块编译成动态对象,主程序使用 dlopen() 打开该动态对象。 然后,它使用 dlsym() 查找模块必须定义的特定初始化函数,并调用它。 例如,您可能会说存储在 foo.so 中的模块必须定义一个名为 module_foo_init() 的函数。

然后,模块的 init 例程通常调用主程序提供的函数来注册某些事件或挂钩的处理程序。

One way is to have the module compiled into a dynamic object, which the main program opens with dlopen(). It then uses dlsym() to look for a specific initialisation function which the module must define, and calls it. For example, you might say that the module stored in foo.so must define a function called module_foo_init().

The module's init routine then typically calls functions provided by main program to register handlers for certain events or hooks.

梦醒时光 2024-08-08 22:48:46

OSGi 是一个广泛使用的 Java 组件框架,是 Eclipse 框架,它也解决了可插入 UI 问题。

OSGi is a component framework for Java that is widely used and is the basis of the Eclipse framework, which addresses pluggable UIs too.

奢欲 2024-08-08 22:48:46

在我工作过的大多数语言中,执行此操作的一般方法是:

  • 您有两个二进制文件、主程序和一个“插件接口库”。
  • 插件接口库基本上只包含接口或抽象基类,或者插件可以编码和扩展的类似内容。
  • 主程序使用反射或其他标准化接口从所有插件库中提取实现该接口的类的实例。 对所有插件重复此步骤,
  • 然后每当需要与插件交互时就对接口进行调用。

设计最后一部分是大部分工作的所在。应该允许哪些调用或挂钩,或者其他什么? 是如何注册的,它们只是函数吗?可能是空的,还是会有某种“钩子注册”? 如果是后者,那将如何工作(我通常将一个对象传递到可用于注册钩子的构造函数中)?

The general way of doing this in most languages I've worked in:

  • You have two binary files, your main program, and a "plugin interface library".
  • The plugin interface library basically only contains either an interface or abstract base class, or something similar that plugins can code against and extend.
  • The main program uses reflection or some other standardized interface to extract an instance of a class that implements the interface from all the plugin libraries. Repeat this step for all plugins
  • Calls are then made against the interface whenever interaction with the plugin is required.

Designing the last part is where most of the work comes in. What calls or hooks, or whatever should be allowed? How are the registered, are they just functions, which can possibly be empty, or will there be some sort of "hook registration"? If the latter, how will that work (I usually pass an object into the constructor that can be used to register hooks with)?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文