在前面的回答(双关语)的基础上，有一个很好的现实例子，就是Groovy对Builders的内置支持。

使用Groovy的MarkupBuilder创建XML 使用Groovy的StreamingMarkupBuilder创建XML Swing构建器 SwingXBuilder

请参阅Groovy文档中的构建器

在前面的回答(双关语)的基础上，有一个很好的现实例子，就是Groovy对Builders的内置支持。

使用Groovy的MarkupBuilder创建XML 使用Groovy的StreamingMarkupBuilder创建XML Swing构建器 SwingXBuilder

请参阅Groovy文档中的构建器

. net StringBuilder类是构建器模式的一个很好的例子。它主要用于在一系列步骤中创建字符串。执行ToString()的最终结果始终是一个字符串，但该字符串的创建取决于使用StringBuilder类中的哪些函数。总而言之，基本思想是构建复杂的对象，并隐藏如何构建对象的实现细节。

下面是在Java中使用模式和示例代码的一些理由，但它是四人组在设计模式中介绍的构建器模式的实现。在Java中使用它的原因也适用于其他编程语言。

正如Joshua Bloch在Effective Java第二版中所说:

当设计那些构造函数或静态工厂具有多个参数的类时，构建器模式是一个很好的选择。

我们都在某些时候遇到过一个类，它有一个构造函数列表，其中每次添加都会添加一个新的选项形参:

Pizza(int size) { ... }        
Pizza(int size, boolean cheese) { ... }    
Pizza(int size, boolean cheese, boolean pepperoni) { ... }    
Pizza(int size, boolean cheese, boolean pepperoni, boolean bacon) { ... }

这被称为伸缩构造函数模式。这种模式的问题是，一旦构造函数有4或5个形参长度，就很难记住形参的所需顺序，以及在给定情况下可能需要哪个特定的构造函数。

可伸缩构造函数模式的另一种选择是JavaBean模式，在该模式中，您调用带有必选参数的构造函数，然后调用以下任何可选设置:

Pizza pizza = new Pizza(12);
pizza.setCheese(true);
pizza.setPepperoni(true);
pizza.setBacon(true);

这里的问题是，由于对象是在多次调用中创建的，因此在构造过程中可能处于不一致的状态。这也需要大量额外的工作来确保线程安全。

更好的选择是使用构建器模式。

public class Pizza {
  private int size;
  private boolean cheese;
  private boolean pepperoni;
  private boolean bacon;

  public static class Builder {
    //required
    private final int size;

    //optional
    private boolean cheese = false;
    private boolean pepperoni = false;
    private boolean bacon = false;

    public Builder(int size) {
      this.size = size;
    }

    public Builder cheese(boolean value) {
      cheese = value;
      return this;
    }

    public Builder pepperoni(boolean value) {
      pepperoni = value;
      return this;
    }

    public Builder bacon(boolean value) {
      bacon = value;
      return this;
    }

    public Pizza build() {
      return new Pizza(this);
    }
  }

  private Pizza(Builder builder) {
    size = builder.size;
    cheese = builder.cheese;
    pepperoni = builder.pepperoni;
    bacon = builder.bacon;
  }
}

注意Pizza是不可变的，并且参数值都在单个位置。因为Builder的setter方法返回Builder对象，所以它们能够被链接。

Pizza pizza = new Pizza.Builder(12)
                       .cheese(true)
                       .pepperoni(true)
                       .bacon(true)
                       .build();

This results in code that is easy to write and very easy to read and understand. In this example, the build method could be modified to check parameters after they have been copied from the builder to the Pizza object and throw an IllegalStateException if an invalid parameter value has been supplied. This pattern is flexible and it is easy to add more parameters to it in the future. It is really only useful if you are going to have more than 4 or 5 parameters for a constructor. That said, it might be worthwhile in the first place if you suspect you may be adding more parameters in the future.

关于这个主题，我从Joshua Bloch的《Effective Java，第二版》一书中借鉴了很多。为了更多地了解这种模式和其他有效的Java实践，我强烈推荐它。

当我想在Java中为XML使用标准XMLGregorianCalendar来对DateTime进行对象封送时，我听到了很多关于使用它是多么沉重和麻烦的评论。我试图控制xs:datetime结构中的XML字段来管理时区，毫秒等。

因此，我设计了一个实用程序，从GregorianCalendar或java.util.Date构建一个xml公历。

由于我工作的地方，我不允许在网上分享它，但这里有一个客户如何使用它的例子。它抽象了XMLGregorianCalendar的细节，并过滤了xs:datetime中较少使用的一些实现。

XMLGregorianCalendarBuilder builder = XMLGregorianCalendarBuilder.newInstance(jdkDate);
XMLGregorianCalendar xmlCalendar = builder.excludeMillis().excludeOffset().build();

假定此模式更像是一个过滤器，因为它将xmlCalendar中的字段设置为未定义，因此将它们排除在外，但它仍然“构建”它。我已经很容易地向构建器添加了其他选项，以创建xs:date和xs:time结构，并在需要时操作时区偏移量。

如果您曾经见过创建和使用XMLGregorianCalendar的代码，您就会看到这是如何使它更容易操作的。

对于多线程问题，我们需要为每个线程构建一个复杂的对象。对象表示正在处理的数据，并且可以根据用户输入进行更改。

我们能用工厂代替吗?是的

为什么我们没有呢?我想建造者更有意义。

工厂用于创建具有相同基本类型的不同类型的对象(实现相同的接口或基类)。

构建器一遍又一遍地构建同一类型的对象，但是构造是动态的，因此可以在运行时更改它。