plugins - 如何创建灵活的插件架构？

Question

我的开发工作中重复的主题是使用或创建内部插件架构。我见过它的实现方式有很多种——配置文件(XML、.conf 等)、继承框架、数据库信息、库等等。根据我的经验:

• 数据库不是存储配置信息的好地方，尤其是与数据混合的配置信息
• 尝试使用继承层次结构进行此操作需要了解要编码的插件，这意味着插件架构并不那么动态
• 配置文件可以很好地提供简单信息，但无法处理更复杂的行为
• 库似乎运行良好，但必须仔细创建单向依赖项。

当我寻求从我使用过的各种架构中学习时，我也在向社区寻求建议。您是如何实现 SOLID 插件架构的？你最严重的失败是什么(或者你见过的最严重的失败)？如果您要实现新的插件架构，您会怎么做？您使用过的哪个 SDK 或开源项目具有良好架构的最佳示例？

我自己找到的一些例子:

• Perl 的 Module::Plugable和 IOC用于 Perl 中的依赖注入(inject)
• The various Spring frameworks (Java、.NET、Python)用于依赖注入(inject)。
• 安 SO question包含 Java 列表(包括 Service Provider Interfaces )
• 安 SO question对于 C++ 来说，指向 Dr. Dobbs article
• 安 SO question关于 ASP.NET MVC 的特定插件想法

这些示例似乎发挥了各种语言的优势。一个好的插件架构是否一定与语言相关？最好使用工具来创建插件架构，还是在自己的以下模型上进行？

Answer 1

这不是一个答案，而是一堆可能有用的评论/示例。

• 使应用程序可扩展的一种有效方法是将其内部公开为脚本语言，并用该语言编写所有顶级内容。这使得它非常可修改并且实际上是面向 future 的(如果您的原语经过精心选择和实现)。 Emacs 就是此类事物的成功案例。与 Eclipse 风格的插件系统相比，我更喜欢它，因为如果我想扩展功能，我不必学习 API 并编写/编译单独的插件。我可以在当前缓冲区本身中编写一个 3 行片段，对其进行评估并使用它。非常平滑的学习曲线和非常令人满意的结果。

• 我稍微扩展了一个应用程序是 Trac 。它具有组件架构，在这种情况下意味着任务被委托(delegate)给通告扩展点的模块。然后，您可以实现适合这些点的其他组件并更改流程。这有点像上面 Kalkie 的建议。

• 另一个好的是 py.test 。它遵循“最好的 API 就是没有 API”的理念，并且完全依赖于在每个级别调用的钩子(Hook)。您可以在根据约定命名的文件/函数中覆盖这些 Hook 并更改行为。您可以查看网站上的插件列表，了解它们的实现速度/容易程度。

一些一般性观点。

• 尽量使不可扩展/用户不可修改的核心尽可能小。将所有可以委托(delegate)的事情委托(delegate)给更高的层，以提高可扩展性。在做出错误选择的情况下，核心需要纠正的东西更少。
• 与上述观点相关的是，您不应该在一开始就对项目的方向做出太多决定。实现所需的最小子集，然后开始编写插件。
• 如果您要嵌入一种脚本语言，请确保它是一种完整的脚本语言，您可以在其中编写通用程序，而不是仅仅用于您的应用程序的玩具语言。
• 尽可能减少样板文件。不要为子类化、复杂的 API、插件注册和类似的事情而烦恼。尽量保持简单，以便容易，而不只是可能扩展。这将使您的插件 API 得到更多使用，并鼓励最终用户编写插件。不仅仅是插件开发者。 py.test 做得很好。据我所知，Eclipse does not 。