构建器模式，具有公共构造器有效答案

【问题标题】：Builder Pattern, with a public Constructor vaild构建器模式，具有公共构造器有效
【发布时间】：2013-08-27 08:20:54
【问题描述】：

我知道关于构建器模式有几个问题。
- 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

到目前为止，我使用了 Bloch Item 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();

但是，如果我不最终确定类，则可以扩展它并在新的构造函数中做各种事情。而且我不确定现在是否没有案例可以解决这个问题。有什么想法吗？

【问题讨论】：

如果有人扩展您的课程，他们的工作就是确保他们正确地这样做。如果他们做得这么差，我想我不会担心会发生什么。你不能解决愚蠢的问题。就此而言，他们可以覆盖每个类的每个方法来做与它应该做的完全相反的事情——你也不能阻止它。所以不用担心。
@GabeSechan 哇，我不能再反对了。类应该为继承而设计，否则应该被禁止。您正在软件中制造未来的错误。
@Christian 制作 Blub 决赛有什么问题？
@Eric Blub 代表一个电气组件，所以也许有一天有人想要更详细地具体化它......所以我只是不想禁止它。
@Christian 抱歉，时间还早。您不能覆盖构造函数。只是不要让构造函数调用任何可以被覆盖的方法。您还应该考虑在 Blub 前面放置一个界面，使其成为最终的，并让未来的客户在需要 Blub 的功能时使用组合。

标签： java design-patterns constructor builder

【解决方案1】：

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

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

这是设计缺陷吗？不会。它可能会导致 API 变得混乱吗？绝对地。特别是随着时间的推移，随着越来越多的代码出现分歧并开始使用方法 A 和 B。您是否要向新开发人员解释他们何时应该使用方法 A 来创建对象或何时应该使用方法 B？

【讨论】：

【解决方案2】：

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

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

这还允许您添加多个静态工厂方法，而不必拥有多个构造函数或具有混淆参数的构造函数。

【讨论】：