如何解决如何创建灵活的插件架构？
这不是一个 答案 ，而是一堆可能有用的评论/示例。
-
使您的应用程序可扩展的一种有效方法是将其内部作为脚本语言公开，并用该语言编写所有顶级内容。这使得它非常可修改并且实际上是面向未来的（如果您的原语选择和实施得当）。这类事情的一个成功案例是 Emacs。我更喜欢 Eclipse 风格的插件系统，因为如果我想扩展功能，我不必学习 API 并编写/编译单独的插件。我可以在当前缓冲区本身中编写一个 3 行代码段，对其进行评估并使用它。非常流畅的学习曲线和非常令人满意的结果。
-
我稍微扩展的一个应用程序是Trac。它有一个组件架构，在这种情况下意味着任务被委派给宣传扩展点的模块。然后，您可以实现适合这些点的其他组件并更改流程。这有点像上面 Kalkie 的建议。
-
另一个很好的是py.test。它遵循“最好的 API 就是没有 API”的理念，并且完全依赖于在每个级别调用的钩子。您可以在根据约定命名的文件/函数中覆盖这些钩子并更改行为。您可以在网站上查看插件列表，了解它们的实施速度/容易程度。
一般几点。
- 尽量保持您的不可扩展/非用户可修改的核心尽可能小。将您所能做的一切委托给更高的层，以增加可扩展性。在出现错误选择的情况下，需要在核心中纠正的东西更少。
- 与上述观点相关的是，你不应该在一开始就对项目的方向做出太多决定。实现所需的最小子集，然后开始编写插件。
- 如果您要嵌入一种脚本语言，请确保它是一种完整的语言，您可以在其中编写通用程序，而不是 仅 用于您的应用程序的玩具语言。
- 尽可能减少样板。不要为子类化、复杂的 API、插件注册和类似的东西而烦恼。尽量保持简单，使其 易于 扩展，而不仅仅是 可以 扩展。这将使您的插件 API 得到更多使用，并鼓励最终用户编写插件。不仅仅是插件开发人员。py.test 做得很好。据我所知，Eclipse没有。
解决方法
在我的开发工作中，一个重复的主题是使用或创建内部插件架构。我已经看到它采用了很多方法——配置文件（XML、.conf
等）、继承框架、数据库信息、库等等。在我的经验中：
- 数据库不是存储配置信息的好地方，尤其是与数据混合的地方
- 尝试使用继承层次结构需要有关要编码的插件的知识，这意味着插件架构并不是那么动态的
- 配置文件可以很好地提供简单的信息，但不能处理更复杂的行为
- 库似乎运行良好，但必须仔细创建单向依赖项。
当我试图从我使用过的各种架构中学习时，我也在向社区寻求建议。您是如何实现 SOLID
插件架构的？你最糟糕的失败是什么（或者你见过的最糟糕的失败）是什么？如果你要实现一个新的插件架构，你会怎么做？您使用过的哪个 SDK
或开源项目具有良好架构的最佳示例？
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。