design-patterns - 构建器模式是否与构造函数中的参数数量有关？

Question

我正在学习设计模式。作为其中的一部分，我将介绍 Builder 设计模式。该定义说“构建器设计模式的目的是将复杂对象的构造与其表示分开”。我试图理解“复杂对象”是什么意思。当我在网上查看时，人们提到构造函数是否有更多参数或
可选参数然后使用构建器对象。

这个解释正确吗？如果我们有可选参数，那么为什么不从构造函数中删除这些参数，如果客户端需要可以使用 set 方法设置该参数？

如果我们有更多的构造函数参数并尝试使用构建器类创建对象，那么客户端可能没有设置一些参数并调用 final方法来获取对象。

Answer 1

以 Pizza 的经典示例为例.

在一些餐厅，比萨饼有不同的变化。
一个配西红柿和金枪鱼，另一个配西红柿、金枪鱼和奶酪，另一个配西红柿、金枪鱼、奶酪和中间的一个鸡蛋。
这是一个 复杂对象 从某种意义上说，它可能允许大量领域/成分的组合。

所以对于同一个对象，这里是披萨，有几种可能的表示(变化)。

如果没有构造此对象的实用方法，您将处理许多处理每个变体的可能构造函数，这在 Pizza 中真是一团糟。类(class)。

你唤起了通过使用一些 setter 来摆脱这些构造函数的事实。
但是在一个好的 OO 设计中，您希望通过一个构造函数或……另一种流畅的方式立即获得一个完整对象的实例，该方法由……构建器模式组成，以避免在完成添加所需成分之前创建不幸的部分 Pizza .

此外，setter 可能会破坏一些应该由对象本身保护的不变量。
事实上，如果代码客户端创建了一个“海王星披萨”而忘记添加像金枪鱼这样的主要成分，它就不再是(有效的)披萨了。

简单的 setter 为任何客户端提供了“操作能力”，这不应该得到它。
而 builder 对象还负责验证必填字段，同时允许省略可选字段。

构建器模式旨在通过流畅的 API 来避免那些“无限”添加构造函数来表示每个比萨饼，该 API 允许比萨饼成分的简单、增量和有凝聚力的组合，然后将一致且完整的对象返回给客户端。