正如马丁·福勒(Martin Fowler)解释的那样,我正在尝试理解和练习plugin pattern。
我可以理解它以何种方式利用separated interface模式,并且它需要工厂根据当前使用的环境(测试,生产,开发等)提供正确的接口实现。 )。但是:
IdGenerator
接口)?DomainObject
)的依赖项?非常感谢您。
答案 0 :(得分:3)
插件模式的目标是提供一个集中的配置运行时来促进模块化和可扩展性。决定选择哪个实现的标准可以是环境,也可以是其他任何东西,如帐户类型、用户组等。工厂只是根据选择标准创建所需插件实例的一种方式。
您的工厂如何读取选择标准(环境状态)取决于您的实施。一些常见的方法是:
Command-Line Argument
,例如,来自不同 CI/CD 流水线阶段的 CLI 调用可以传递一个 dev/staging/production 参数YAML Config Files
可以反序列化为对象或解析Class Annotations
使用环境标记每个实现Feature Flags
,例如SaaS 喜欢 Launch DarklyDependency Injection
框架,如 Spring IoCProduct Line Engineering
软件,如 Big LeverREST Endpoint
,例如http://localhost/test/order 可以在不通知任何客户的情况下创建测试订单对象HTTP Request Parameter
,例如标题或正文中的字段由于 DomainObject
调用工厂以创建具有所需实现的对象,因此工厂将成为域对象的依赖项。话虽如此,现代方法是使用依赖注入 (DI) 库 (Guice, Dagger) 或具有内置 DI 的框架 (Spring DI, .Net Core )。在这些情况下,仍然依赖于 DI 库或框架,但不明确依赖于任何工厂类。
注意:Plugin
的第 499-503 页中描述的 PEAA
设计模式是 Rice 和 Foemmel 编写的,而不是 Martin Fowler。
答案 1 :(得分:1)
您将希望获得“企业应用程序体系结构模式”的完整PFD。 Fowler网站上可见的基本上是任何一章的前半页:)
所描述的基本上是polymorphism背后的想法的扩展版本。
我不认为“插件”实际上可以描述为“模式”。这更像是其他设计选择的结果。
您所拥有的是.. emm ...“包装”,其中每个包装中的主类都实现了第三方接口。这些软件包中的每个软件包都有其内部依赖性(其他类,甚至其他库),这些依赖性用于某些特定任务。每个软件包都有其配置(可以通过DIC config添加),并且每个软件包都已在您的主应用程序中“注册”。
提及工厂几乎是red herring,因为如今这些功能将使用DIC来应用。