你什么时候会使用建造者模式？

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

想要改进这个问题吗？通过编辑这篇文章来更新问题，使其仅关注一个问题。

9 年前已关闭。

Answer 1

下面是一些争论在 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();

这使得代码易于编写，并且非常易于阅读和理解。在本示例中，可以修改构建方法以在参数复制后检查参数将构建器添加到 Pizza 对象，如果提供了无效的参数值，则抛出 IllegalStateException。这种模式很灵活，将来可以轻松向其添加更多参数。仅当构造函数的参数超过 4 或 5 个时，它才真正有用。也就是说，如果您怀疑将来可能会添加更多参数，那么首先这可能是值得的。

我从《Effective Java，第二版》一书中大量借用了有关此主题的内容 /em> 约书亚·布洛赫。要了解有关此模式和其他有效 Java 实践的更多信息，我强烈推荐它。

Answer 2

考虑一家餐馆。 “今天的饭菜”的创建是一种工厂模式，因为你告诉厨房“给我今天的饭菜”，厨房（工厂）根据隐藏的标准决定生成什么对象。

如果您订购定制披萨，则会出现生成器。在这种情况下，服务员告诉厨师（建造者）“我需要一个披萨；添加奶酪、洋葱和培根！”因此，构建器公开了生成的对象应具有的属性，但隐藏了如何设置它们。

Answer 3

恕我直言，构建器和工厂之间的主要区别在于，当您需要做很多事情来构建对象时，构建器非常有用。例如想象一个 DOM。您必须创建大量节点和属性才能获得最终对象。当工厂可以在一个方法调用中轻松创建整个对象时，就可以使用工厂。

使用构建器的一个示例是构建 XML 文档，我在构建 HTML 片段时使用了此模型，例如我可能有一个构建器用于构建特定类型的表，它可能具有以下方法（参数是未显示）：

BuildOrderHeaderRow()
BuildLineItemSubHeaderRow()
BuildOrderRow()
BuildLineItemSubRow()

然后该构建器将为我输出 HTML。这比遍历大型过程方法更容易阅读。

查看维基百科上的构建器模式。

Answer 4

.NET StringBuilder 类是构建器模式的一个很好的示例。它主要用于通过一系列步骤创建字符串。执行 ToString() 得到的最终结果始终是一个字符串，但该字符串的创建根据使用 StringBuilder 类中的函数而有所不同。总而言之，基本思想是构建复杂的对象并隐藏其构建方式的实现细节。

Answer 5

我一直不喜欢构建器模式，因为它笨拙、唐突，而且经常被经验不足的程序员滥用。这种模式只有在您需要从某些需要初始化后步骤的数据组装对象时才有意义（即一旦收集了所有数据 - 对其进行处理）。相反，99% 的情况下，构建器只是简单地用于初始化类成员。

在这种情况下，最好在类中简单地声明 withXyz(...) 类型 setter，并让它们返回对其自身的引用。

考虑一下：

public class Complex {

    private String first;
    private String second;
    private String third;

    public String getFirst(){
       return first; 
    }

    public void setFirst(String first){
       this.first=first; 
    }

    ... 

    public Complex withFirst(String first){
       this.first=first;
       return this; 
    }

    public Complex withSecond(String second){
       this.second=second;
       return this; 
    }

    public Complex withThird(String third){
       this.third=third;
       return this; 
    }

}


Complex complex = new Complex()
     .withFirst("first value")
     .withSecond("second value")
     .withThird("third value");

现在我们有一个整洁的单个类，它管理自己的初始化，并且执行与构建器几乎相同的工作，只是它更加优雅。

Answer 6

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

我们可以用工厂代替吗？是的，

我们为什么不呢？我想 Builder 更有意义。

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

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

Answer 7

当您有很多选择需要处理时，您可以使用它。想想 jmock 之类的东西：

m.expects(once())
    .method("testMethod")
    .with(eq(1), eq(2))
    .returns("someResponse");

感觉更自然，而且……可能。

还有 xml 构建、字符串构建和许多其他内容。想象一下，如果 java.util.Map 已作为构建器放置。你可以做这样的事情：

Map<String, Integer> m = new HashMap<String, Integer>()
    .put("a", 1)
    .put("b", 2)
    .put("c", 3);

Answer 8

在研究 Microsoft MVC 框架时，我想到了构建器模式。我在 ControllerBuilder 类中遇到了该模式。该类将返回控制器工厂类，然后使用该工厂类来构建具体的控制器。

我看到使用构建器模式的优点是，您可以创建自己的工厂并将其插入框架中。

@Tetha，可能有一家由意大利人经营的餐厅（框架），供应披萨。为了准备披萨，意大利人（对象生成器）使用 Owen（工厂）和披萨底座（基类）。

现在印度人从意大利人手中接管了这家餐厅。印度餐厅（框架）提供薄饼而不是披萨。为了准备 dosa 印度人（对象构建者）使用带有 Maida（基类）的煎锅（工厂）

如果你看看场景，食物是不同的，食物准备的方式是不同的，但在同一家餐厅（在同一框架下） ）。餐厅的建造方式应该能够支持中餐、墨西哥菜或任何美食。框架内的对象生成器有助于插入您想要的菜肴。例如

class RestaurantObjectBuilder
{
   IFactory _factory = new DefaultFoodFactory();

   //This can be used when you want to plugin the 
   public void SetFoodFactory(IFactory customFactory)
   {
        _factory = customFactory;
   }

   public IFactory GetFoodFactory()
   {
      return _factory;
   }
}

Answer 9

基于之前的答案（双关语），一个很好的现实示例是 Groovy 的内置支持建设者。

• 使用 Groovy 的 MarkupBuilder 创建 XML
• 使用 Groovy 的 StreamingMarkupBuilder 创建 XML
• Swing Builder
• SwingXBuilder

请参阅构建器 在 Groovy 文档

Answer 10

构建器的另一个优点是，如果您有一个工厂，那么您的代码中仍然存在一些耦合，因为要使工厂正常工作，它必须知道它可能创建的所有对象。如果添加另一个可以创建的对象，则必须修改工厂类以包含他。这也发生在抽象工厂中。

另一方面，对于构建器，您只需为这个新类创建一个新的具体构建器。导演类将保持不变，因为它在构造函数中接收构建器。

此外，构建器有很多种风格。神风特攻队雇佣兵又给出了一份。

Answer 11

/// <summary>
/// Builder
/// </summary>
public interface IWebRequestBuilder
{
    IWebRequestBuilder BuildHost(string host);

    IWebRequestBuilder BuildPort(int port);

    IWebRequestBuilder BuildPath(string path);

    IWebRequestBuilder BuildQuery(string query);

    IWebRequestBuilder BuildScheme(string scheme);

    IWebRequestBuilder BuildTimeout(int timeout);

    WebRequest Build();
}

/// <summary>
/// ConcreteBuilder #1
/// </summary>
public class HttpWebRequestBuilder : IWebRequestBuilder
{
    private string _host;

    private string _path = string.Empty;

    private string _query = string.Empty;

    private string _scheme = "http";

    private int _port = 80;

    private int _timeout = -1;

    public IWebRequestBuilder BuildHost(string host)
    {
        _host = host;
        return this;
    }

    public IWebRequestBuilder BuildPort(int port)
    {
        _port = port;
        return this;
    }

    public IWebRequestBuilder BuildPath(string path)
    {
        _path = path;
        return this;
    }

    public IWebRequestBuilder BuildQuery(string query)
    {
        _query = query;
        return this;
    }

    public IWebRequestBuilder BuildScheme(string scheme)
    {
        _scheme = scheme;
        return this;
    }

    public IWebRequestBuilder BuildTimeout(int timeout)
    {
        _timeout = timeout;
        return this;
    }

    protected virtual void BeforeBuild(HttpWebRequest httpWebRequest) {
    }

    public WebRequest Build()
    {
        var uri = _scheme + "://" + _host + ":" + _port + "/" + _path + "?" + _query;

        var httpWebRequest = WebRequest.CreateHttp(uri);

        httpWebRequest.Timeout = _timeout;

        BeforeBuild(httpWebRequest);

        return httpWebRequest;
    }
}

/// <summary>
/// ConcreteBuilder #2
/// </summary>
public class ProxyHttpWebRequestBuilder : HttpWebRequestBuilder
{
    private string _proxy = null;

    public ProxyHttpWebRequestBuilder(string proxy)
    {
        _proxy = proxy;
    }

    protected override void BeforeBuild(HttpWebRequest httpWebRequest)
    {
        httpWebRequest.Proxy = new WebProxy(_proxy);
    }
}

/// <summary>
/// Director
/// </summary>
public class SearchRequest
{

    private IWebRequestBuilder _requestBuilder;

    public SearchRequest(IWebRequestBuilder requestBuilder)
    {
        _requestBuilder = requestBuilder;
    }

    public WebRequest Construct(string searchQuery)
    {
        return _requestBuilder
        .BuildHost("ajax.googleapis.com")
        .BuildPort(80)
        .BuildPath("ajax/services/search/web")
        .BuildQuery("v=1.0&q=" + HttpUtility.UrlEncode(searchQuery))
        .BuildScheme("http")
        .BuildTimeout(-1)
        .Build();
    }

    public string GetResults(string searchQuery) {
        var request = Construct(searchQuery);
        var resp = request.GetResponse();

        using (StreamReader stream = new StreamReader(resp.GetResponseStream()))
        {
            return stream.ReadToEnd();
        }
    }
}

class Program
{
    /// <summary>
    /// Inside both requests the same SearchRequest.Construct(string) method is used.
    /// But finally different HttpWebRequest objects are built.
    /// </summary>
    static void Main(string[] args)
    {
        var request1 = new SearchRequest(new HttpWebRequestBuilder());
        var results1 = request1.GetResults("IBM");
        Console.WriteLine(results1);

        var request2 = new SearchRequest(new ProxyHttpWebRequestBuilder("localhost:80"));
        var results2 = request2.GetResults("IBM");
        Console.WriteLine(results2);
    }
}

Answer 12

我在本地消息库中使用了构建器。库核心从线路接收数据，使用 Builder 实例收集数据，然后，一旦 Builder 确定它已获得创建 Message 实例所需的一切，Builder.GetMessage() 就会使用从 Builder 收集的数据构建消息实例。金属丝。

Answer 13

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

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

由于我的工作地点的原因，我不允许在没有法律的情况下在线共享它，但这里有一个客户如何使用它的示例。它抽象了细节并过滤了一些较少用于 xs:datetime 的 XMLGregorianCalendar 实现。

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

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

如果您曾经见过创建和使用 XMLGregorianCalendar 的代码，您就会发现这如何使其更易于操作。