插件设计模式解释（如 Martin Fowler 所述）

Question

正如 Martin Fowler 所解释的那样，我正在尝试理解和练习插件模式。

我可以理解它以何种方式使用分离的接口模式，并且它需要一个工厂根据当前使用的环境（测试、生产、开发等）提供接口的正确实现。但：

• 工厂究竟是如何读取环境值并决定创建哪个对象（实现IdGenerator接口）的？
• 工厂是域对象 ( DomainObject)的依赖项吗？

非常感谢。

Answer 1

插件模式的目标是提供一个集中的配置运行时来促进模块化和可扩展性。决定选择哪个实现的标准可以是环境，也可以是其他任何东西，如帐户类型、用户组等。工厂只是根据选择标准创建所需插件实例的一种方式。

实施选择标准

您的工厂如何读取选择标准（环境状态）取决于您的实施。一些常见的方法是：

• Command-Line Argument例如，来自不同 CI/CD 流水线阶段的 CLI 调用可以传递一个 dev/staging/production 参数
• YAML Config Files 可以反序列化为对象或解析
• Class Annotations 用环境标记每个实现
• Feature Flags，例如像Launch Darkly这样的 SaaS
• Dependency Injection像Spring IoC这样的框架
• Product Line Engineering像大杠杆这样的软件
• REST Endpoint, 例如 http://localhost/test/order 可以在不通知任何客户的情况下创建测试订单对象
• HTTP Request Parameter，例如标题或正文中的字段

对工厂的依赖

由于DomainObject调用工厂以创建具有所需实现的对象，因此工厂将成为域对象的依赖项。话虽如此，现代方法是使用依赖注入 (DI) 库（Guice、Dagger）或具有内置 DI 的框架（Spring DI、.Net Core）。在这些情况下，仍然依赖于 DI 库或框架，但不明确依赖于任何工厂类。

注意：Plugin pp.499-503 中描述的设计模式PEAA是由 Rice 和 Foemmel 编写的，而不是 Martin Fowler。

Answer 2

您将希望获得“企业应用程序架构模式”的完整 PFD。Fowler 网站上可见的基本上是任何章节的前半页:)
所描述的基本上是多态性背后思想的扩展版本。

我认为“插件”实际上不能被描述为“模式”。它更像是其他设计选择的结果。

你所拥有的是.. emm ...“包”，其中每个包中的主类都实现了第三方接口。每个包也有其内部依赖项（其他类甚至其他库），用于某些特定任务。每个包都有它的配置（可以通过 DIC 配置添加），并且每个包都会在您的主应用程序中“注册”。

提到工厂几乎是转移注意力，因为如今该功能将使用 DIC 来应用。