なぜ型がそのビルダーと結合されるのでしょうか？

私は最近、Code Reviewで私のJavaの回答を削除しました。

private Person(PersonBuilder builder) {

やめる。赤旗。PersonBuilderはPersonを構築します。それは人について知っています。PersonクラスはPersonBuilderについて何も知らないはずです-それは単なる不変の型です。ここで、Aに依存するBに依存するAに依存する循環カップリングを作成しました。

Personはパラメータを取得するだけです。構築せずにPersonを作成するクライアントは、それを実行できる必要があります。

私は下票で平手打ちされ、それを（引用して）赤旗と言った、なぜ？ここでの実装は、Joshua Blochが彼の「Effective Java」本（アイテム＃2）で示したものと同じ形をしています。

したがって、Javaでビルダーパターンを実装する正しい方法は、ビルダーをネスト型にし（これはこの質問の目的ではありません）、製品を作成することです（ビルドされているオブジェクトのクラス）このように、ビルダーに依存します：

private StreetMap(Builder builder) {
    // Required parameters
    origin      = builder.origin;
    destination = builder.destination;

    // Optional parameters
    waterColor         = builder.waterColor;
    landColor          = builder.landColor;
    highTrafficColor   = builder.highTrafficColor;
    mediumTrafficColor = builder.mediumTrafficColor;
    lowTrafficColor    = builder.lowTrafficColor;
}

_{^{https://en.wikipedia.org/wiki/Builder_pattern#Java_example}}

同じBuilderパターンの同じWikipediaページには、C＃の実装が大きく異なります（そして、はるかに柔軟です）。

//Represents a product created by the builder
public class Car
{
    public Car()
    {
    }

    public int Wheels { get; set; }

    public string Colour { get; set; }
}

ご覧のとおり、ここの製品はBuilderクラスについて何も知らないため、直接コンストラクター呼び出し、抽象ファクトリー、またはビルダーによってインスタンス化できることに気をつけています-私が理解している限り、創造的なパターンの製品は、それを作成しているものについて何も知る必要はありません。

私は、ビルダーパターンを使用して、コンストラクターが多数のオプション引数で肥大化するような型を作り直すことができるという反論（明らかにBlochの本で明らかに防御されている）を受けました。だから、私はこのサイトで少し研究したと思っていたと思っていたものに固執する代わりに、私が疑ったように、この議論は水を保持していないことがわかった。

それで、取引は何ですか？そもそも存在してはならない問題に対して、過剰に設計されたソリューションを考え出すのはなぜですか？ジョシュアブロッホを台座から1分間離すと、2つの具体的なタイプを結合し、それをベストプラクティスと呼ぶ1つの正当な理由を見つけることができますか？

これはすべて、私にとってカーゴカルトプログラミングの続きです。

私はそれが赤旗であるというあなたの主張に同意しません。また、Builderパターンを表す1つの正しい方法があるという、カウンターポイントの表現に反対します。

私には 1つの質問があります：Builderは型のAPIの必要な部分ですか？ここで、PersonBuilderはPerson APIの必要な部分ですか？

妥当性がチェックさ不変、および/または緊密にカプセル化されたPersonクラスをすることを完全に合理的である必然（関わらず、そのビルダーがネストまたは隣接しているかどうかの）それが提供するビルダを使用して作成すること。そうすることで、Personはすべてのフィールドをprivateまたはpackage-privateおよびfinalに保つことができます。また、作業中の場合は、クラスを変更のために開いたままにしておくことができます。（最終的には修正のために閉じられ、拡張のために開かれるかもしれませんが、それは現在重要ではなく、特に不変のデータオブジェクトについては議論の余地があります。）

単一のパッケージレベルAPIデザインの一部として、提供されたPersonBuilderを介してPersonを作成する必要がある場合、循環カップリングは適切であり、ここで赤いフラグは保証されません。特に、あなたはそれを議論の余地のない事実であり、API設計の意見や選択ではないと述べたので、それは悪い反応に貢献したかもしれません。私はあなたをdownvotedていないだろうが、私はそうするために他の誰かのせいにしていない、と私が「何ワラントdownvote」の議論の残り残しておきますコードレビューのヘルプセンターとメタ。Downvotesが発生します。「平手打ち」ではありません。

もちろん、Personオブジェクトを作成するために多くの方法を開いたままにしたい場合、PersonBuilderはコンシューマーまたはユーティリティになります。Personクラスは、Personが直接依存するべきではありません。この選択はより柔軟に思えますが（オブジェクト作成オプションをこれ以上必要としない人はいますか？） 。Builderが、多くのオプションフィールドを持つコンストラクターまたは変更に対して開かれているコンストラクターを表現または置換することを意図している場合、クラスの長いコンストラクターは、実装の詳細を隠したままにすることができます。（公式で必要なBuilderは、独自の構築ユーティリティの作成を妨げるものではなく、構築ユーティリティが上記の最初の質問のようにBuilderをAPIとして使用する可能性があることにも留意してください。）

ps：リストしたコードレビューサンプルには不変のPersonがありますが、Wikipediaの反例にはゲッターとセッターを含む可変のCarがリストされています。言語と不変条件の一貫性を保つと、必要な機械が車から省略されているのが見やすくなります。

議論の中で「権威への訴え」が使われたとき、それがどれほど厄介なものになるかを理解しています。議論は独自のIMOに基づいているべきであり、そのような尊敬される人のアドバイスを指すことは間違っていませんが、アリストテレスがそう言ったので、太陽が地球の周りを移動することを知っているので、それ自体では完全な議論とは考えられません。

そうは言っても、あなたの議論の前提は同じだと思います。2つの具体的なタイプを結合してベストプラクティスと呼ぶべきではありません。

カップリングが問題であるという議論が有効であるためには、それが作り出す特定の問題が必要です。このアプローチがこれらの問題の影響を受けない場合、この形式のカップリングに問題があると論理的に主張することはできません。したがって、ここであなたの主張を述べたいのであれば、このアプローチがこれらの問題にどのように影響しているのか、および/またはビルダーを切り離すことで設計がどのように改善されるのかを示す必要があると思います。

率直に言って、私は結合アプローチがどのように問題を引き起こすかを見るのに苦労しています。クラスは完全に結合されていますが、ビルダーはクラスのインスタンスを作成するためだけに存在します。別の見方をすると、コンストラクターの拡張機能として使用できます。

型がビルダーと結合される理由に答えるには、そもそもなぜビルダーを使用するのかを理解する必要があります。具体的には、Blochは、コンストラクターパラメーターが多数ある場合はビルダーを使用することをお勧めします。それがビルダーを使用する唯一の理由ではありませんが、私はそれが最も一般的であると推測します。要するに、ビルダーはこれらのコンストラクターパラメーターの代わりであり、多くの場合、ビルダーはビルドしているのと同じクラスで宣言されます。したがって、包含クラスはすでにビルダーの知識を持っているため、コンストラクター引数として渡すことで変更されることはありません。それが、型がそのビルダーと結合される理由です。

多数のパラメーターがあるのは、ビルダーを使用する必要があることを意味するのはなぜですか？さて、多数のパラメーターを持つことは、現実の世界では珍しいことではなく、単一の責任原則に違反するものでもありません。また、10個のStringパラメーターがあり、どのパラメーターがどのパラメーターであり、nullにする必要があるのが5番目または6番目のストリングであるかどうかを記憶しようとしている場合にも、それは面倒です。ビルダーを使用すると、パラメーターの管理が簡単になります。また、本を読んで調べる必要のある他のクールなことができます。

タイプと連動していないビルダーはいつ使用しますか？一般に、オブジェクトのコンポーネントがすぐに利用できず、それらの部分を持つオブジェクトが構築しようとしている型を知る必要がない場合、または制御できないクラスのビルダーを追加する場合。

創造的なパターンの製品は、それを作成するものについて何も知る必要はありません。

Personこのクラスは、それを作成しているものを知りません。パラメーターを持つコンストラクターのみがあります。パラメーターの型の名前は... Builderで終わりますが、実際には何も強制しません。結局のところ単なる名前です。

このビルダーは、栄光に満ちた^1つの構成オブジェクトです。 そして、構成オブジェクトは実際には、互いに属するプロパティをグループ化するだけです。クラスのコンストラクターに渡されるという目的のためだけにそれらが互いに属している場合は、そうしてください！originおよびdestinationのStreetMap例は両方ともタイプPointです。各ポイントの個々の座標をマップに渡すことは可能でしょうか？確かに、プロパティはPoint一緒に属します。さらに、構築に役立つあらゆる種類のメソッドを使用できます。

¹違いは、ビルダーは単なるデータオブジェクトではなく、これらのチェーンセッター呼び出しを許可することです。主に自分自身を構築する方法に関するものです。Builder

ミックスに少しコマンドパターンを追加しましょう。よく見ると、ビルダーは実際にはコマンドであるためです。

1. アクションをカプセル化します：別のクラスのメソッドを呼び出す
2. そのアクションを実行するために必要な情報を保持します：メソッドのパラメーターの値

ビルダーの特別な部分は次のとおりです。

1. 呼び出されるメソッドは、実際にはクラスのコンストラクターです。今、それを創造的なパターンと呼んでください。
2. パラメーターの値は、ビルダー自体です

Personコンストラクターに渡されるものはビルドできますが、必ずしもそうする必要はありません。単純な古い構成オブジェクトまたはビルダーの可能性があります。

いいえ、それらは完全に間違っており、あなたは絶対に正しいです。そのビルダーモデルは馬鹿げています。コンストラクターの引数は、Personのビジネスには関係ありません。このビルダーはユーザーにとって便利なだけであり、それ以上のものではありません。