ビルダーパターンがこのように実装されることが多いのはなぜですか？

多くの場合、（Javaでの）ビルダーパターンの実装は次のようになります。

public class Foo {
    private Foo(FooBuilder builder) {
        // get alle the parameters from the builder and apply them to this instance
    }

    public static class FooBuilder {
        // ...
        public Foo build() {
            return new Foo(this); // <- this part is what irritates me
        }
    }
}

ここにも例：

• /programming/25130510/builder-pattern-in-java
• https://www.javacodegeeks.com/2013/01/the-builder-pattern-in-practice.html

なぜ人々はビルダーとタイプの間に強い（相互の）依存関係を導入して導入するのですか？

編集：つまり、その性質上、ビルダーはインスタンスを構築したいクラスに関連付けられていることを知っています（FooBuilder -> Foo）。私が質問しているのは：なぜ他の方法が必要なのですか（Foo -> FooBuilder）

それどころかFoo、ビルダーが作成されたときに新しいインスタンスを作成Fooし、適切なビルダーメソッドが呼び出されたときにインスタンスにフィールドを設定する実装は（それほど頻繁ではありませんが）あります。流暢なAPIがまだあり、クラスをビルダーに関連付けないため、このアプローチの方が好きです。この他のアプローチの欠点はありますか？

つまり、半分構築された状態でFooが存在しないことになります。

思い浮かぶいくつかの理由：

ビルダーは本来、構築しているクラスに関連付けられています。ビルダーの中間状態はコンストラクターの部分的な適用と考えることができるため、結合が強すぎるという主張は説得力がありません。

ビルダー全体を渡すことで、MyClassのフィールドを最終的にすることができ、MyClassについての推論が容易になります。フィールドがfinalでない場合は、ビルダーよりも流暢なセッターを簡単に使用できます。

ビルダーは、メソッドで設定された可変フィールドを保持します。実際のクラス（Foo）はfinal、ビルダーから不変フィールドを作成できます。

つまり、ビルダーはステートフルなクラスです。

しかし、ビルダーは他にも呼び出すことができたでしょうnew Foo(x, y, z)。それはより一方向の、より良いスタイルの私見でしょう。その時と同じように、アンチパターン、FooBuilderフィールドなどは不可能です。一方、FooBuilderはデータの完全性を保証します。

一方、FooBuilderは2つの役割を果たします。流れるようなAPIで構築するためと、コンストラクターにデータを提示するためです。コンストラクタのイベント型クラスです。過剰に設計されたコードでは、コンストラクターのパラメーターをいくつかのFooConstructorParamsに保持できます。

「ビルダー」は通常、特に不変クラスのコンテキストで「テレスコープコンストラクターの問題」を解決するために使用されるためです。本格的な例については、このリンクを参照してください。

代替案がどのようになるかを検討します。

 public static class FooBuilder {
    // works with immutable classes, but leads to telescoping constructor
    public Foo build() {
        return new Foo(par1, par2, par3, ....); 
    }
 }

または：

 public static class FooBuilder {
    // does not work for immutable classes:
    public Foo build() {
        var foo = new Foo(); 
        foo.Attribute1=par1;
        foo.Attribute2=par2;
        //...
        return foo;
    }
 }

したがって、特に不変クラスの場合、多数のパラメーターを持つコンストラクターが必要ない場合、実際には代替手段はありません。