我不是在寻找特定于语言的答案，而是在寻找用于实现插件系统的通用模型(如果我们想知道的话，我正在使用Python)。我有自己的主意(注册回调，就是这样)，但是我知道其他人也存在。通常使用什么，还有什么合理的呢？

What do you mean by a plugin system? Does Dependency Injection and IOC containers sounds like a good solution?

我的意思是，嗯，一种在不更改基础程序的情况下将功能插入基础程序的方法。出发时我无意定义它。依赖注入看起来并不特别适合我在做什么，但是我对它们了解不多。

解决方案

在Python中，我们可以使用setuptools和pkg_resources提供的入口点系统。每个入口点都应该是一个函数，该函数返回有关插件的名称，作者，设置和拆卸功能等信息。

一个简单的插件架构可以使用该插件应实现的所有方法定义一个插件接口。该插件处理来自应用程序的事件，并且可以使用应用程序的标准代码，模型对象等来完成任务。除了要覆盖而不是实现之外，与ASP.NET Form基本上相同。

没有人教我这一部分，而且我也不是专家，但是我觉得：一般而言，插件的稳定性要比其应用程序差，因此该应用程序应始终处于控制状态，并且仅使插件有机会采取行动。如果插件可以注册观察者，则应尝试/捕获对委托的调用。

我们可能会对软件工程电台的一集非常感兴趣。

为了将来参考，我在此处转载了由Erich Gamma，肯特·贝克撰写的出色的《 Eclipse贡献》中给出的"促成规则"(替代链接)。

Invitation Rule - Whenever possible, let others contribute to your contributions.
  Lazy Loading Rule - Contributions are only loaded when they are needed.
  Safe Platform Rule - As the provider of an extension point, you must protect yourself against misbehavior on the part of extenders.
  Fair Play Rule - All clients play by the same rules, even me.
  Explicit Extension Rule - Declare explicitly where a platform can be extended.
  Diversity Rule - Extension points accept multiple extensions.
  Good Fences Rule - When passing control outside your code, protect yourself.
  Explicit API Rule - separate the API from internals.
  Stability Rule - Once you invite someone to contribute, don?t change the rules.
  Defensive API Rule - Reveal only the API in which you are confident, but be prepared to reveal more API as clients ask for it.

抽象工厂怎么样？基础程序定义了抽象概念之间的交互方式，但是调用者必须提供实现。