如何创建灵活的插件架构? [英] How To Create a Flexible Plug-In Architecture?

问题描述

在我的开发工作中一个重复的主题是使用或创建内部插件架构.我已经看到它采用了多种方式 - 配置文件(XML、.conf 等)、继承框架、数据库信息、库等.根据我的经验:

A repeating theme in my development work has been the use of or creation of an in-house plug-in architecture. I've seen it approached many ways - configuration files (XML, .conf, and so on), inheritance frameworks, database information, libraries, and others. In my experience:

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

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

As I seek to learn from the various architectures I've worked with, I'm also looking to the community for suggestions. How have you implemented a SOLID plug-in architecture? What was your worst failure (or the worst failure you've seen)? What would you do if you were going to implement a new plug-in architecture? What SDK or open source project that you've worked with has the best example of a good architecture?

我自己发现的几个例子:

A few examples I've been finding on my own:

• Perl 的 Module::Plugable和 IOC 用于 Perl 中的依赖注入
• 各种 Spring 框架(Java、.NET、Python)用于依赖注入.
• 一个带有 Java 列表的SO 问题(包括服务提供者接口)
• C++ 的 SO 问题指向 博士.多布斯文章
• 关于 ASP 的特定插件想法的SO 问题.NET MVC

• Perl's Module::Plugable and IOC for dependency injection in Perl
• The various Spring frameworks (Java, .NET, Python) for dependency injection.
• An SO question with a list for Java (including Service Provider Interfaces)
• An SO question for C++ pointing to a Dr. Dobbs article
• An SO question regarding a specific plugin idea for ASP.NET MVC

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

These examples seem to play to various language strengths. Is a good plugin architecture necessarily tied to the language? Is it best to use tools to create a plugin architecture, or to do it on one's own following models?

推荐答案

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

This is not an answer as much as a bunch of potentially useful remarks/examples.

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

• One effective way to make your application extensible is to expose its internals as a scripting language and write all the top level stuff in that language. This makes it quite modifiable and practically future proof (if your primitives are well chosen and implemented). A success story of this kind of thing is Emacs. I prefer this to the eclipse style plugin system because if I want to extend functionality, I don't have to learn the API and write/compile a separate plugin. I can write a 3 line snippet in the current buffer itself, evaluate it and use it. Very smooth learning curve and very pleasing results.

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

One application which I've extended a little is Trac. It has a component architecture which in this situation means that tasks are delegated to modules that advertise extension points. You can then implement other components which would fit into these points and change the flow. It's a little like Kalkie's suggestion above.

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

Another one that's good is py.test. It follows the "best API is no API" philosophy and relies purely on hooks being called at every level. You can override these hooks in files/functions named according to a convention and alter the behaviour. You can see the list of plugins on the site to see how quickly/easily they can be implemented.

一些一般要点.

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

• Try to keep your non-extensible/non-user-modifiable core as small as possible. Delegate everything you can to a higher layer so that the extensibility increases. Less stuff to correct in the core then in case of bad choices.
• Related to the above point is that you shouldn't make too many decisions about the direction of your project at the outset. Implement the smallest needed subset and then start writing plugins.
• If you are embedding a scripting language, make sure it's a full one in which you can write general programs and not a toy language just for your application.
• Reduce boilerplate as much as you can. Don't bother with subclassing, complex APIs, plugin registration and stuff like that. Try to keep it simple so that it's easy and not just possible to extend. This will let your plugin API be used more and will encourage end users to write plugins. Not just plugin developers. py.test does this well. Eclipse as far as I know, does not.

这篇关于如何创建灵活的插件架构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！