构建器模式:为什么许多示例实现与GOF图不同？

Question

在以前的post中，有人建议StringBuilder是生成器设计模式的一个例子，但是它与四人帮描述的版本有很大的不同，而且他们描述的设计模式似乎更像是如下所示：http://www.oodesign.com/builder-pattern.html

这两个示例都是Builder设计模式吗?如果是，它们之间的共同点是什么？

还有，导演身上的钻石的用途是什么？这是否意味着一个或多个混凝土建造者的组合？

Answer 1

实现可能彼此不同，但一般来说，它们遵循相同的方法。

正如您可能知道的，Builder模式可以与药物配方并列在一起-例如，医生可以在一个配方中添加越来越多的药物处方，最后，当准备好时，给您完整的配方。

当使用生成器模式构造对象时，我们做一些类似的事情-调用方法，这些方法用作如何构建对象的指令，当我们准备好时，我们使用终端方法来获取对象，例如名为build()。

构建器实现的另一个示例是java.util.stream.Stream类，它是Java8中Stream API的一部分。

它以非常相似的方式工作-您可以在Stream上调用所需的尽可能多的非终端操作，并最终根据所提供的条件列表获得构建的 Stream。例如：

List<String> names = Arrays.asList("John", "Peter", "Stephen");
//Let's build a Stream, which will give a list of the sizes of each of our names
List<Integer> namesSizes = names
                          .stream()
                          .map(name -> name.length())
                          .collect(Collectors.toList()); //terminal operation

更多信息：

• Examples of the GoF design patterns

Answer 2

我也对此感到非常困惑。据我所知，许多“构建器设计模式”的例子都是基于Josh Bloch's effective Java Item#2的，这可以被认为是GoF的构建器模式的简化。看起来Bloch的实现目标是引入简单性，当有太多的方法来构造一个具体对象时-或者一个具体对象表示自身的方式略有不同，从而导致太多具有相似类型参数的构造函数-例如:具有可选和强制属性。(使用Bloch的构造器模式解决了伸缩构造函数的反模式)

GoF通过“导向器”对整个创建过程有了另一个间接的层次，它封装了关于构建产品需要步骤的知识-这个创建算法在产品中仍然是通用的-以及一个接口/基类来表示必要的构建器接口(契约)，它知道如何做每一步。每个构建器实现都会返回自己的具体产品。

Answer 3

Builder是一种创造性的设计模式，它允许您一步一步地构造复杂对象。该模式允许您使用相同的构造代码生成对象的不同类型和表示。

GOF图(GOF builder)只是实现Builder模式思想的一个例子。

在这里是重要的概念，而不是实现，因为相同的想法可以有不同的实现和不同的图。

单例模式也是如此。其思想是将类的实例化限制为一个“单个”实例。这可以通过多种方式来实现。GOF图(GOF builder)只是实现Builder模式思想的一个例子。

在这里是重要的概念而不是实现，因为相同的想法可以有不同的实现和不同的实现。

单例模式也是如此。其思想是将类的实例化限制为一个“单个”实例。这可以通过多种方式来实现。