Book-深入设计模式-生成器模式
https://refactoringguru.cn/design-patterns/builder
生成器模式
亦称： 建造者模式、Builder
生成器模式是一种创建型设计模式， 使你能够分步骤创建复杂对象。 该模式允许你使用相同的创建代码生成不同类型和形式的对象。
解决方案
生成器模式建议将对象构造代码从产品类中抽取出来， 并将其放在一个名为生成器的独立对象中。
生成器模式让你能够分步骤创建复杂对象。 生成器不允许其他对象访问正在创建中的产品。
主管
进一步将用于创建产品的一系列生成器步骤调用抽取成为单独的主管类。 主管类可定义创建步骤的执行顺序， 而生成器则提供这些步骤的实现。
严格来说， 程序中并不一定需要主管类。 客户端代码可直接以特定顺序调用创建步骤。 不过，主管类中非常适合放入各种例行构造流程， 以便在程序中反复使用。
此外， 对于客户端代码来说， 主管类完全隐藏了产品构造细节。 客户端只需要将一个生成器与主管类关联， 然后使用主管类来构造产品， 就能从生成器处获得构造结果了。
生成器模式结构
生成器模式适合应用场景
- 使用生成器模式可避免 “重叠构造函数 （telescoping constructor）” 的出现。
- 当你希望使用代码创建不同形式的产品 （例如石头或木头房屋） 时， 可使用生成器模式。
- 使用生成器构造组合树或其他复杂对象。
生成器模式让你能分步骤构造产品。 你可以延迟执行某些步骤而不会影响最终产品。 你甚至可以递归调用这些步骤， 这在创建对象树时非常方便。
生成器在执行制造步骤时， 不能对外发布未完成的产品。 这可以避免客户端代码获取到不完整结果对象的情况。
实现方法
-
清晰地定义通用步骤， 确保它们可以制造所有形式的产品。 否则你将无法进一步实施该模式。
-
在基本生成器接口中声明这些步骤。
-
为每个形式的产品创建具体生成器类， 并实现其构造步骤。
不要忘记实现获取构造结果对象的方法。 你不能在生成器接口中声明该方法， 因为不同生成器构造的产品可能没有公共接口， 因此你就不知道该方法返回的对象类型。 但是， 如果所有产品都位于单一类层次中， 你就可以安全地在基本接口中添加获取生成对象的方法。 -
考虑创建主管类。 它可以使用同一生成器对象来封装多种构造产品的方式。
-
客户端代码会同时创建生成器和主管对象。 构造开始前， 客户端必须将生成器对象传递给主管对象。 通常情况下， 客户端只需调用主管类构造函数一次即可。 主管类使用生成器对象完成后续所有制造任务。 还有另一种方式， 那就是客户端可以将生成器对象直接传递给主管类的制造方法。
-
只有在所有产品都遵循相同接口的情况下， 构造结果可以直接通过主管类获取。 否则， 客户端应当通过生成器获取构造结果。
生成器模式优缺点
优点
- 你可以分步创建对象， 暂缓创建步骤或递归运行创建步骤。
- 生成不同形式的产品时， 你可以复用相同的制造代码。
- 单一职责原则。 你可以将复杂构造代码从产品的业务逻辑中分离出来。
缺点
由于该模式需要新增多个类， 因此代码整体复杂程度会有所增加。
与其他模式的关系
-
在许多设计工作的初期都会使用工厂方法模式 （较为简单， 而且可以更方便地通过子类进行定制）， 随后演化为使用抽象工厂模式、 原型模式或生成器模式 （更灵活但更加复杂）。
-
生成器重点关注如何分步生成复杂对象。 抽象工厂专门用于生产一系列相关对象。 抽象工厂会马上返回产品， 生成器则允许你在获取产品前执行一些额外构造步骤。
-
你可以在创建复杂组合模式树时使用生成器， 因为这可使其构造步骤以递归的方式运行。
-
你可以结合使用生成器和桥接模式： 主管类负责抽象工作， 各种不同的生成器负责实现工作。
-
抽象工厂、 生成器和原型都可以用单例模式来实现。