2

我知道关于构建器模式有几个问题。
-在子类的构造器中使用构建器模式
-什么时候使用构建器模式
- Java 改进特定类
的构建器模式 -构建器设计模式为什么我们需要导向器

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

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

4

2 回答 2

1

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

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

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

于 2014-02-03T11:32:27.247 回答
0

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

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

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

于 2013-08-25T00:44:12.030 回答