gof-factory

一句话概述

集中管理要实例化的具体类选择，并对客户端隐藏这一选择——分为三种范围逐步扩大的形式：简单工厂（一个方法选择类型）、工厂方法（子类选择类型）、抽象工厂（相关类型的产品族）。

何时使用此技能

• 客户端代码中充斥着 new ConcreteX() 这样的选择逻辑，而具体选择取决于输入数据、配置或环境。
• 两个并行的类层次结构需要一同选择相匹配的实现（例如，NYStylePizzaStore 应生成 NYStyleDough、NYStyleSauce——这就是抽象工厂）。
• 子类应决定要实例化哪种具体类型，同时共享周边工作流——工厂方法。
• 构造过程本身有构造函数无法保证的不变条件。

何时不使用此技能

• 只有一种具体类型；直接调用其构造函数即可。
• 一个简单的顶层函数（fun parsePayment(json): Payment）就足够——仅为单个函数命名一个 *Factory 类毫无益处。
• 构造确实很简单，仅仅因为“工厂是最佳实践”就增加间接层，纯属形式主义。

核心内容

三种范围逐步扩大的形式，各自解决更具体的问题：

简单工厂（严格来说并非 GoF 模式，但它是入门形式）。一个接收判别值（字符串、枚举、标志）并返回正确具体实例的方法或类。集中管理 new。适用于调用处已知判别值的情况。

工厂方法。将具体类的选择推迟到子类。基类实现一个包含 factoryMethod()（抽象方法）的工作流；每个子类都会重写该方法，返回相应的具体类型。适用于周边工作流相同，但要生成的类型因子类而异的情况。

抽象工厂。用于生成相关产品族的工厂。工厂接口为每种产品类型声明一个方法（例如，createDough、createSauce）；具体工厂生成风格相匹配的实现。适用于必须成套创建相匹配类型的情况。

决策启发

• 从简单工厂开始。只有在确实存在工作流继承层次结构时，才升级为工厂方法。只有在必须保持产品族一致时，才升级为抽象工厂（纽约风格配纽约风格；芝加哥风格配芝加哥风格；绝不混搭）。
• 在目标类本身定义一个静态创建方法通常就足够了（例如，Pizza.of(type)）——不要条件反射般地引入独立的工厂类。
• 同时负责持久化或修改全局状态的工厂职责过多——让创建过程保持纯粹。

反模式

• 每种类型都创建一个工厂类（OrderFactory、CustomerFactory、AddressFactory），而构造函数本就足够——这是模式作秀。
• “FactoryFactory”——几乎总是过度设计的表现。
• 只有一个具体工厂时使用抽象工厂——这种抽象没有可服务的多样性。

另请参阅

• gof-singleton — 工厂通常是单例；请考虑其中的权衡。
• gof-strategy — 工厂通常生成策略；两种模式可以组合使用。
• gof-kotlin-idioms — Kotlin 的 companion object 工厂方法、使用 when 匹配的密封类工厂，以及构造函数表达式，可以在大多数情况下替代独立的工厂类。

参考资料

• Head First Design Patterns（第 2 版），第 4 章（“运用面向对象的妙处烘焙：工厂模式”）——以披萨店为例介绍简单工厂、工厂方法和抽象工厂。