Builderパターン（主にJava）の多くの実装を見てきました。それらはすべて、エンティティクラス（クラスとしましょうPerson）とビルダークラスを持っていますPersonBuilder。ビルダーはさまざまなフィールドを「スタック」し、new Person渡された引数とともにを返します。Personクラス自体にすべてのビルダーメソッドを配置するのではなく、明示的にビルダークラスが必要なのはなぜですか？

例えば：

class Person {

  private String name;
  private Integer age;

  public Person() {
  }

  Person withName(String name) {
    this.name = name;
    return this;
  }

  Person withAge(int age) {
    this.age = age;
    return this;
  }
}

簡単に言えます Person john = new Person().withName("John");

なぜPersonBuilderクラスが必要なのですか？

私が見る唯一の利点は、Personフィールドをとして宣言できることfinalです。したがって、不変性が保証されます。

あなたができるように、それはだ不変と名前付きパラメータをシミュレートすると同時に。

Person p = personBuilder
    .name("Arthur Dent")
    .age(42)
    .build()
;

それは、その状態が設定されるまでミットを人から遠ざけ、一度設定されると、それを変更させませんが、すべてのフィールドは明確にラベル付けされます。Javaの1つのクラスだけでこれを行うことはできません。

Josh Blochs Builder Patternについて話しているようです。これをGang of Four Builderパターンと混同しないでください。これらは異なる獣です。どちらも建設上の問題を解決しますが、方法はかなり異なります。

もちろん、別のクラスを使用せずにオブジェクトを構築できます。しかし、その後、選択する必要があります。Javaのように、名前のないパラメーターを名前のあるパラメーターでシミュレートする機能を失うか、オブジェクトの存続期間中不変のままでいる機能を失います。

不変の例、パラメーターの名前はありません

Person p = new Person("Arthur Dent", 42);

ここでは、単一の単純なコンストラクターですべてを構築しています。これにより、不変のままになりますが、名前付きパラメーターのシミュレーションを失います。それは多くのパラメーターで読みにくくなります。コンピュータは気にしませんが、人間にとっては難しいです。

従来のセッターでシミュレートされた名前付きパラメーターの例。不変ではありません。

Person p = new Person();
p.name("Arthur Dent");
p.age(42);

ここでは、すべてをセッターで構築し、名前付きパラメーターをシミュレートしていますが、もはや不変ではありません。セッターを使用するたびにオブジェクトの状態が変わります。

クラスを追加することで得られるのは、両方を行うことができるということです。

build()年齢フィールドがない場合の実行時エラーで十分であれば、検証を実行できます。これをアップグレードしage()て、コンパイラエラーで呼び出されることを強制できます。Josh Blochビルダーパターンではありません。

そのためには、内部ドメイン固有言語（iDSL）が必要です。

これは、あなたは彼らが呼ぶことを要求することができますage()し、name()呼び出す前にbuild()。しかし、this毎回戻るだけではできません。返される各ものは、次のものを呼び出すことを強制する異なるものを返します。

使用方法は次のようになります。

Person p = personBuilder
    .name("Arthur Dent")
    .age(42)
    .build()
;

でもこれは：

Person p = personBuilder
    .age(42)
    .build()
;

は、age()によって返される型を呼び出す場合にのみ有効であるため、コンパイラエラーが発生しますname()。

これらのiDSLは非常に強力（JOOQやJava8ストリームなど）で、特にコード補完を備えたIDEを使用する場合は非常に便利ですが、セットアップにはかなりの作業が必要です。それらに対してかなりのソースコードが書かれているもののためにそれらを保存することをお勧めします。

ビルダークラスを使用/提供する理由：

• 不変オブジェクトを作成するには—既に特定した利点。構築に複数のステップが必要な場合に便利です。FWIW、不変性は、メンテナンス可能なバグのないプログラムを作成するための私たちの探求において重要なツールと見なされるべきです。
• 最終（不変の可能性がある）オブジェクトのランタイム表現が読み取りおよび/またはスペース使用量に対して最適化されているが、更新用には最適化されていない場合。ここでは、StringとStringBuilderが良い例です。文字列を繰り返し連結することはあまり効率的ではないため、StringBuilderは、追加に適した別の内部表現を使用しますが、スペースの使用には適さず、通常のStringクラスほど読み取りや使用には適していません。
• 構築されたオブジェクトを構築中のオブジェクトから明確に分離するため。このアプローチでは、建設中から建設中への明確な移行が必要です。消費者にとって、構築中のオブジェクトと構築済みのオブジェクトを混同する方法はありません。型システムがこれを強制します。つまり、このアプローチを使用して「成功の落とし穴」に陥ることがあり、他のユーザー（または自分自身）が使用する（APIやレイヤーなど）ために抽象化する場合、これは非常に良いことです。事。

1つの理由は、渡されたすべてのデータがビジネスルールに従うようにすることです。

この例ではこれを考慮していませんが、誰かが空の文字列または特殊文字で構成される文字列を渡したとしましょう。名前が実際に有効な名前であることを確認することに基づいて、何らかのロジックを実行する必要があります（実際には非常に難しいタスクです）。

特にロジックが非常に小さい場合（たとえば、年齢が負でないことを確認するだけの場合）は、すべてをPersonクラスに入れることができますが、ロジックが大きくなるにつれて、それを分離するのが理にかなっています。

これについては、他の回答で見たものとは少し異なる角度です。

withFooここでのアプローチは、セッターのように動作しますが、クラスが不変性をサポートするように見えるように定義されているため、問題があります。Javaクラスでは、メソッドがプロパティを変更する場合、「set」でメソッドを開始するのが習慣です。私は標準としてそれを決して愛していませんでしたが、あなたが何か他のものをするならば、それは人々を驚かせるでしょう、そして、それは良くありません。ここにある基本的なAPIで不変性をサポートできる別の方法があります。例えば：

class Person {
  private final String name;
  private final Integer age;

  private Person(String name, String age) {
    this.name = name;
    this.age = age;
  }  

  public Person() {
    this.name = null;
    this.age = null;
  }

  Person withName(String name) {
    return new Person(name, this.age);
  }

  Person withAge(int age) {
    return new Person(this.name, age);
  }
}

不適切に部分的に構築されたオブジェクトを防ぐ方法ではあまり提供しませんが、既存のオブジェクトへの変更を防ぎます。この種のことはおそらくばかげているでしょう（JB Builderも同様です）。はい、より多くのオブジェクトを作成しますが、これはあなたが思うほど高価ではありません。

ほとんどの場合、この種のアプローチはCopyOnWriteArrayListなどの並行データ構造で使用されます。そして、これは不変性が重要である理由を示唆しています。コードをスレッドセーフにしたい場合、ほとんどの場合、不変性を考慮する必要があります。Javaでは、各スレッドは変数状態のローカルキャッシュを保持できます。1つのスレッドが他のスレッドで行われた変更を確認するには、同期ブロックまたは他の同時実行機能を使用する必要があります。これらのいずれも、コードにオーバーヘッドを追加します。しかし、変数が最終的なものであれば、何もする必要はありません。値は常に初期化された値になるため、すべてのスレッドは何があっても同じものを見ます。

ここでまだ明示的に言及されていない別の理由は、build()メソッドがすべてのフィールドが「直接設定された、または他のフィールドの他の値から派生した有効な値を含むフィールドである」ことを確認できることです。これはおそらく最も失敗しやすいモードですそうでなければ発生します。

もう1つの利点は、Personオブジェクトのライフタイムがより単純になり、不変式のセットが単純になることです。あなたが持っていることを知っていればPerson p、あなたはを持っていp.nameて有効ですp.age。「年齢は設定されているが名前は設定されていない場合、または名前は設定されているが年齢は設定されていない場合はどうでしょう」などの状況を処理するようにメソッドを設計する必要はありません。これにより、クラスの全体的な複雑さが軽減されます。

ビルダーは、インターフェイスまたは抽象クラスを返すように定義することもできます。ビルダーを使用してオブジェクトを定義できます。ビルダーは、設定されているプロパティや設定されているプロパティなどに基づいて、返される具体的なサブクラスを決定できます。

Builderパターンは、プロパティを設定することにより、オブジェクトを段階的に構築/作成するために使用され、すべての必要なフィールドが設定されると、buildメソッドを使用して最終オブジェクトを返します。新しく作成されたオブジェクトは不変です。ここで注意すべき主な点は、最終ビルドメソッドが呼び出されたときにのみオブジェクトが返されることです。これにより、すべてのプロパティがオブジェクトに設定され、ビルダークラスから返されたときにオブジェクトが矛盾した状態にならないことが保証されます。

ビルダークラスを使用せず、すべてのビルダークラスメソッドをPersonクラス自体に直接配置する場合、最初にオブジェクトを作成し、作成されたオブジェクトでセッターメソッドを呼び出す必要があります。オブジェクトのプロパティを設定します。

したがって、ビルダークラス（つまり、Personクラス自体以外の外部エンティティ）を使用することにより、オブジェクトが矛盾した状態にならないようにします。

ビルダーオブジェクトを再利用する

他の人が述べたように、オブジェクトを検証するための不変性とすべてのフィールドのビジネスロジックの検証は、別個のビルダーオブジェクトの主な理由です。

ただし、再利用性も別の利点です。非常によく似た多くのオブジェクトをインスタンス化する場合は、Builderオブジェクトに小さな変更を加えて、インスタンス化を続行できます。ビルダーオブジェクトを再作成する必要はありません。この再利用により、ビルダーは多くの不変オブジェクトを作成するためのテンプレートとして機能できます。それは小さな利点ですが、有用なものになる可能性があります。

実際には、クラス自体にビルダーメソッドを設定できますが、それでも不変性は保持されます。これは、既存のオブジェクトを変更するのではなく、ビルダーメソッドが新しいオブジェクトを返すことを意味します。

これは、初期（有効/有用）オブジェクトを取得する方法がある場合（たとえば、すべての必須フィールドを設定するコンストラクター、またはデフォルト値を設定するファクトリーメソッド）にのみ機能し、追加のビルダーメソッドは、既存のもの。 これらのビルダーメソッドは、途中で無効または一貫性のないオブジェクトを取得しないようにする必要があります。

もちろん、これは新しいオブジェクトがたくさんあることを意味し、オブジェクトの作成にコストがかかる場合は、これを行うべきではありません。

ビジネスオブジェクトの1つにHamcrestマッチャーを作成するためのテストコードでそれを使用しました。正確なコードは思い出せませんが、次のようになりました（簡略化）。

public class CustomerMatcher extends TypeSafeMatcher<Customer> {
    private final Matcher<? super String> nameMatcher;
    private final Matcher<? super LocalDate> birthdayMatcher;

    @Override
    protected boolean matchesSafely(Customer c) {
        return nameMatcher.matches(c.getName()) &&
               birthdayMatcher.matches(c.getBirthday());
    }

    private CustomerMatcher(Matcher<? super String> nameMatcher,
                            Matcher<? super LocalDate> birthdayMatcher) {
        this.nameMatcher = nameMatcher;
        this.birthdayMatcher = birthdayMatcher;
    }

    // builder methods from here on

    public static CustomerMatcher isCustomer() {
        // I could return a static instance here instead
        return new CustomerMatcher(Matchers.anything(), Matchers.anything());
    }

    public CustomerMatcher withBirthday(Matcher<? super LocalDate> birthdayMatcher) {
        return new CustomerMatcher(this.nameMatcher, birthdayMatcher);
    }

    public CustomerMatcher withName(Matcher<? super String> nameMatcher) {
        return new CustomerMatcher(nameMatcher, this.birthdayMatcher);
    }
}

次に、ユニットテストで（適切な静的インポートを使用して）次のように使用します。

assertThat(result, is(customer().withName(startsWith("Paŭlo"))));