Builder デザイン パターンと Factory デザイン パターンの違いは何ですか?

どちらがより有利で、その理由は?

これらのパターンをテストして比較/対比したい場合、調査結果をグラフとして表すにはどうすればよいですか?

別のクラスのパブリック クラス メンバーとして、ビルダー パターンから多くの注目を集めています。

保護されたコンストラクターに注意してください-ビルダーを使用してパーツを取得する必要がある方法が好きです。への呼び出し

うまくいきます。私がやりたいことは、このビルダーを使用して、タイプに基づいて特別な種類のパーツを提供することです (たとえば)。

そして、ビルダーへのわずかな変更:

しかし、これは機能しません。Part.Builder は、SpecialPart の保護されたコンストラクターを認識できません。Builder を Part の子孫と連携させ、ビルダーに必須の同じセマンティクスを取得するにはどうすればよいですか?

この質問が何度も聞かれることは知っていますが、これについてもっと明確にしたいだけです。ビルダー パターンはファクトリー パターンを置き換えることができますか。

はいビルダーパターンは、複雑なオブジェクトを段階的に作成して返します。これは、ファクトリパターンでも実行できます。

作成中の単体テスト用のテストデータを簡単に作成できるように、ビルダーの構築を開始しました。

ビルダーの基本構造は次のとおりです。

このパターンの使用法は次のようになります。

私はそれで満足しています...しかし、質問があるMyClassのは、自明ではないプロパティがある場合です....デフォルト値でそれを構築する方法について少し確信が持てません。

私の仮定は、ビルダーを作成し、MySecondClassそれを使用してデフォルトの実装を作成することです。

私の仮定が正しく、ベストプラクティスであることを誰かが確認できますか?

私は現在、自分の仮定をテストしている最中ですが、Google を使用して見つけることができるビルダー パターンの唯一の例は、参照型ではなく値型であるプロパティのみを構築したため、StackOverflow でこのアイデアを文書化すると思いました。

動機

最近、コンストラクターに多くのパラメーターを渡さずに複雑なオブジェクトを初期化する方法を探しました。ビルダーパターンで試してみましたが、本当に必要な値をすべて設定したかどうかをコンパイル時に確認できないのが気になりません。

従来のビルダーパターン

ビルダーパターンを使用してComplexオブジェクトを作成すると、引数が何に使用されているかを確認しやすくなるため、作成はより「タイプセーフ」になります。

しかし今、私は問題を抱えています。それは、重要なパラメータを簡単に見逃してしまう可能性があるということです。build()メソッド内で確認できますが、それは実行時のみです。コンパイル時に、何かを見逃した場合に警告するものは何もありません。

強化されたビルダーパターン

今の私のアイデアは、必要なパラメーターを見逃した場合に「思い出させる」ビルダーを作成することでした。私の最初の試みは次のようになります：

ご覧のとおり、ビルダークラスの各セッターは異なる内部ビルダークラスを返します。各内部ビルダークラスは正確に1つのsetterメソッドを提供し、最後のクラスはbuild（）メソッドのみを提供します。

これで、オブジェクトの構築は次のようになります。

...しかし、必要なパラメータを忘れる方法はありません。コンパイラはそれを受け入れません。

オプションのパラメータ

オプションのパラメーターがある場合は、最後の内部ビルダークラスを使用してBuilder4、「従来の」ビルダーと同じようにパラメーターを設定し、それ自体を返します。

質問

• これはよく知られているパターンですか？特別な名前はありますか？
• 落とし穴はありますか？
• コードの行数を減らすという意味で、実装を改善するためのアイデアはありますか？

Builder パターンと Flyweight パターンの使用方法の違いは何ですか? どちらも多数のオブジェクトを処理します。

この質問があちこちで何度か出てくるのを見てきましたが、満足のいく答えは見つかりませんでした。

ウィキペディアから:

Builder は、複雑なオブジェクトを段階的に構築することに重点を置いています。Abstract Factory は、製品オブジェクトのファミリ (単純または複雑) を強調します。Builder は最終ステップとして製品を返しますが、Abstract Factory に関する限り、製品はすぐに返されます。

しかし、クライアントにとっては同じことではないでしょうか。オブジェクトが構築されると完全なオブジェクトを取得するため、追加機能はありません。

私が見る唯一の方法は、ビルダーの実装のための構造を強制するために、コンストラクターコードを段階的に編成する方法です。これは素晴らしいことですが、抽象的な工場からの大きな一歩ではありません。

ウィキペディアからのこの次のビットは、私の要点を理解するための良い参考資料です。

多くの場合、設計は Factory Method (より単純で、カスタマイズ可能で、サブクラスが急増) を使用して開始され、設計者がより柔軟性が必要な場所を発見するにつれて、Abstract Factory、Prototype、または Builder (より柔軟でより複雑) に進化します。

その場合、Abstract Factory から Builder に変更する場合、システムにどのような複雑さを導入する必要がありますか?

私の要点は、Abstract Factory では不十分であり、代わりに Builder が必要になることが明らかな場所を見つけて例を挙げられないということです。

単体テストでテスト データを作成するために、データ ビルダーを作成しました。私のデータ ビルダーは、すべてのプロパティのデフォルトを作成するので、それらを使用するテストでは、テストに適用可能なプロパティのみを指定する必要があります。

次のビルダーを検討してください。

これを行うことで、ID が重要であるが注文が重要ではないテストで顧客を作成する必要がある場合、次のようにオブジェクトを作成できます。

これは良い考えですか？それとも、非プリミティブ プロパティがどのように構築されるべきかを想定するのが最善ではない理由はありますか?

構造体を取り、不変のラッパーと、新しいインスタンスを段階的に構築するための「ビルダー」クラスを自動的に生成するツール/ライブラリは何ですか?

入力例:

出力例:

このような「ツール」は、IDE プラグインであるか、リフレクションを使用して実行時に新しいクラスを生成することができます。

例は C# ですが、静的に型付けされた OO 言語 (Java、Scala、C++ など) のソリューションに興味があります。

望ましい機能:

• ビルダー クラスの構造体からメソッドを再作成します。
• 不変クラスの構造体から非破壊的なメソッドを再作成します (特にEquals()andGetHashCode()およびインターフェイス メソッド) 。
• IFooReaderまた、不変とビルダーの両方によって実装される、各構造体メンバーの読み取り専用プロパティを含むインターフェイスを生成します。
• フィールドのクラスに不変の同等物がある場合、不変のクラスで不変のバージョンを使用します (参照型であるプロパティを持つオブジェクトの C# でビルダーを作成する方法も参照してください)。eg List->ReadOnlyCollectionなど。
• または、ビルダー クラスを入力として使用します (ビルダーは、構造体に委譲する代わりに自動プロパティを使用します)。
• Cloneメソッドを事前定義する必要はありません

「このようなツールは使用しないでください...」という回答も大歓迎です。

従来のコードベースには、あまりにも多くのフィールド/責任を持つ非常に大きなクラスがあります。これが Pizza オブジェクトであると想像してください。

次のような非常に詳細なフィールドがあります。

• ペパロニ
• ソーセージ
• hasBellPeppers

これらの 3 つのフィールドが真である場合、最高のピザがあることを私は知っています。ただし、このクラスは拡張や変更に対してオープンではないため、PizzaType や isSupreme() などを追加することはできません。コードベース全体の人々は、同じif(a && b && c) then isSupreme)ロジックをいたるところに複製しています。この問題はかなりの数の概念で発生するため、このオブジェクトを多くのサブオブジェクトに分解する方法を探しています。たとえば、疑似後方ビルダー パターンです。

これは正しいアプローチですか？このパターンはすでに存在しますか？