Question

我知道有关构建器模式的几个问题。
- Use builder pattern from the constructor in a subclass
- When would you use the builder pattern
- Java improving builder pattern on a specific class
- Builder design pattern why do we need a director

到目前为止，我使用了布洛赫第2项中描述的构建器模式。

昨天我改变了一些小细节。我为默认值添加了一个公共构造函数。因此，您可以将Builder用于复杂对象，也可以将构造函数用于具有必要值的简单对象。

public class Blub {
  private final String id;
  public Blub( final String id ) {
    this( Blub.Builder(id) );
  }

  private Blub( Builder builder ) {
    this.id = builder.id; 
  }

  public static class Builder {
    private final String id;
    public Builder( final String id ) {
      this.id = id;
    }

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

但我不确定这是否有设计缺陷。因为如果我最后完成课程，我肯定没有缺点。因此，在简单的情况下，可以调用Blub构造函数。

new Blub("1a");

而不是

(new Blub.Builder("1a")).build();

但是如果我没有最终确定类，那么可以扩展它并在新构造函数中执行所有类型的操作。而且我不确定现在是否有任何案例可以解决这个问题。有什么想法吗？

Answer 1

如果你打算使用Builder（或者工厂模式），那么参与化构造函数通常也是违反直觉的（除非它们是依赖项，你使用的是IoC）。你基本上打破了正交性和DRY原则。构建器和工厂模式通常用于解决构造挑战，其中创建实例非常重要或容易出错。

在你的情况下，这似乎不是。

这是一个设计缺陷吗？不可以。它是否可能导致API变得混乱？绝对。特别是随着时间的推移，随着更多的代码分散并开始使用方法A和B.您是否应该向新开发人员解释他们应该使用方法A来创建对象还是应该使用方法B？

Answer 2

我经常做的一件事是提供构建器和静态工厂方法来构建常见的简单案例。通过这种方式，您仍然可以拥有私有构造函数，并获得构建默认情况的干净方法。

Blub blub = Blub.createWithId("id");

这也允许你添加几个静态工厂方法，而不必有多个构造函数或带有混乱参数的构造函数。

Builder模式，公共构造函数有效

2 个答案: