問題タブ [builder-pattern]

ビルダーパターンは不変オブジェクトを作成するのに人気がありますが、ビルダーを作成するにはプログラミングのオーバーヘッドがあります。だから、なぜ単純に構成オブジェクトを使用しないのだろうか。

ビルダーの使用法は次のようになります。

これが非常に読みやすく簡潔であることは明らかですが、ビルダーを実装する必要があります。

私の考えは、次のような単純な構成オブジェクトを使用してコードを減らすことです。

使用法：

この使用法にはさらに数行が必要ですが、非常に読みやすくなっていますが、実装ははるかに単純であり、ビルダーパターンに精通していない人にとっては理解しやすいかもしれません。ちなみに、このパターンの名前はありますか？

私が見落としていた構成アプローチの欠点はありますか？

ファクトリークラスやメソッド、パターンなどの使用に関しては、私は完全な初心者です。実際、Java関連の質問を閲覧するときにStackoverflowで最初にそれらを学びました:-)

私の以前の質問に答えて、GUIの開発におけるビルダーパターンの使用を検討することが提案されたので、このパターンを使用してアプリケーションのユーザーインターフェイスをどのように組み合わせることができるかを示すよく理解できる例を探しています。メソッドチェーンなど。

読んでくれてありがとう。

コンストラクター自体の中でさまざまなビルド手順を実行できないのはなぜですか。ビルドステップが引数をとる場合、それらをコンストラクターに引数として提供し、コンストラクター内で使用してオブジェクトを作成できないのはなぜですか。

私の知る限り、ビルダーパターンでは、特定のオブジェクトを作成するクライアント。それでは、コンストラクターの代わりにビルダーを使用して、作成されるクラスのオブジェクトに引数を指定する利点は何ですか?

Builder は Cloneable を実装し、clone() をオーバーライドします。ビルダーのすべてのフィールドをコピーする代わりに、不変クラスはビルダーのプライベート クローンを保持します。これにより、新しいビルダーを返し、不変インスタンスのわずかに変更されたコピーを簡単に作成できます。

これで行けます

Cloneable インターフェースは多少壊れていると言われていますが、これは適切な Java コーディング慣行に違反していませんか? この構造に問題はありますか?

現在、プロジェクトにBuilderパターンのインスタンスがあります。現在、サポートされている出力形式はCSVですが、YAMLを含めたいと思います。簡単だと思いました。タイプを変更するためのすべてのサポートコードがあります。

私は自分自身が少し複雑になっていることに気づいています。Builderパターンを使用する目的は、出力ファイルを段階的に作成することでした。私には、これはYAMLと直接矛盾しているように見えます-すべてのオブジェクトを配列に入れて、YAML :: dump（）を呼び出します。

良いニュースは、私がそれらのオブジェクトの配列を持っているということです。ディレクターに渡されます。これは、Directorのconstruct（）メソッドからのスニペットです。

CSV形式とYAML形式の両方に対応する方法がわかりません。何か案は？

私のプロジェクトでは、DTOでいっぱいの2つのパッケージ、ゲッターとセッターだけのPOJOがあります。それらが単純なJavaBeanであることが重要ですが（たとえば、Apache CXFがそれらを使用してWebサービスXSDなどを作成するため）、そのようなプログラムはひどくエラーが発生しやすくなります。

私は流暢なインターフェースとビルダーオブジェクトを好むので、maven/gmavenを使用してDTOのビルダーを自動的に作成します。したがって、上記のコードの場合、aFooBuilderが自動的に生成され、次のように使用できます。

また、生成されたビルダーの単体テストも自動的に生成します。単体テストは、上記のコード（ビルダーバージョンと非ビルダーバージョン）の両方を生成し、両方のバージョンがとに関して同等であることを表明しequals()ますhashcode()。それを実現する方法は、すべてのプロパティタイプにデフォルトが設定されたグローバルにアクセス可能なマップを用意することです。このようなもの：

もう1つの重要な側面は、pojoにコレクションメンバーが存在する場合があることです。例えば：

しかし、私のビルダーでは、この場合から2つのメソッドを生成したいと思います。setメソッドとaddメソッドです。

のプロパティフィールドにカスタムアノテーションを追加することでこれを解決しましたFoo

ビルダービルダー（原文のまま）はアノテーションを読み取り、生成するメソッドのジェネリックタイプとして値を使用します。

私たちは今、質問に近づいています（申し訳ありませんが、簡潔さは私のメリットの1つではありません:-)）。

このビルダーアプローチは複数のプロジェクトで使用できることに気付いたので、Mavenプラグインに変えることを考えています。私はMavenプラグインを生成する方法について完全に明確なので、それは質問の一部ではありません（また、有効なJavaソースコードを生成する方法でもありません）。私の問題は次のとおりです。一般的な依存関係（プロジェクトとプラグインの間）を導入せずに、上記の2つの問題に対処するにはどうすればよいですか。

<Question>

1. 生成された単体テストのデフォルト値を取得するには、Defaultsクラス（または同様のメカニズム）が必要です（これは概念の重要な部分であり、完全にテストされていない場合、自動生成されたビルダーは信頼できません）。各プロジェクトには独自のドメインオブジェクトがあるので、この問題を解決するための優れた一般的な方法を考え出すのを手伝ってください。

2. ジェネリック型をビルダージェネレーターに伝達する一般的な方法が必要です。プロジェクトとプラグインの両方が同じアノテーションを認識する必要があるため、私が使用している現在のアノテーションベースのバージョンは満足のいくものではありません。

</Question>

何か案は？

ところで：ビルダーを使用することの本当の重要なポイントは、オブジェクトを不変にすることです。標準のJavaBeanが必要なため、私のものを不変にすることはできませんが、AspectJを使用して、ビルダー以外のコードベースのどこでもset-methodsもコンストラクターも呼び出されないように強制します。したがって、実用的な目的では、結果のオブジェクトは不変です。 。

また：はい、私は既存のBuilder-generatorIDEプラグインを知っています。それは私の目的に合わないので、自動化されたソリューションが必要です。これは、基盤となるコードが変更されたときに常に最新の状態になります。

Matt Bは、ビルダーの生成方法に関する情報を要求しました。これが私がすることです：

リフレクションごとにクラスを読み取り、Introspector.getBeanInfo(clazz).getPropertyDescriptors()プロパティ記述子の配列を取得するために使用します。私のすべてのビルダーには、上記の場合の基本クラスAbstractBuilder<T>がありTます。これがAbstractBuilderクラスのコードFooです。配列内のすべてのプロパティについて、プロパティの名前でメソッドが生成されます。これは、次の実装になります。PropertyDescriptorFooBuilder.bar(String)

このbuild()メソッドはAbstractBuilder、オブジェクトをインスタンス化し、そのプロパティマップ内のすべてのプロパティを割り当てます。

最近、要求されたパラメーターの数に関するクラスを作成しようとすると、私は引き裂かれました。

非常に単純なコンストラクターの例:

対

どちらの方法も有効なアプローチです。最初の方法は、ハンバーガーに何が入っているかを正確に示し、引数をより一般的なクラスに分解するため、結合が少なくなります。オブジェクト グラフが単純であるため、一般的にテストが簡単だと思います。

しかし、2 番目の方法ははるかに単純でクリーンであり、おそらくハンバーガーにはより多くの材料が必要になる可能性があるため、最初の方法の議論は非常に膨らむ可能性があります。

このような状況でどの方法が推奨されるか知りたいです。よりクリーンでより結合されたコード、またはより冗長な方法を選択してください。

私は最近、研究グループでデザインパターンを研究してきましたが、ビルダーパターンは、多くの（場合によってはオプションの）パーツで構成される複雑なオブジェクトを作成するのに非常に役立つことがあることを理解しました。

しかし、ビルダーがやりすぎているポイントはありますか？オブジェクトの多くの異なる組み合わせを持つクラスがあるとしましょう。何十もの異なるビルダーを作成する代わりに、それに適した別のパターンがありますか？完全に特定のビルダーを作成しないことで、必要なビルダーの数を減らすことは可能ですか？

私の研究グループと私が何度も訪れた例は、自動車会社のWebサイトなどの自動車メーカーでした。どの自動車会社にも数十台の車があり、それぞれにさまざまな機能、色、追加機能などがあります。私が理解しているように、ビルダーは作成しているオブジェクトに固有である必要があるため、この例にビルダーパターンを適用すると数百台になります。 「RedSUVWithSunroofBuilder」、「BlueSUVWithSunroofBuilder」、「RedSUVBuilder」などのようなビルダー。

ビルダーパターンを使用して、作成する必要のあるビルダーの数を減らすためにこれらの値の一部を渡すことができなかった理由はありますか？たとえば、RedSUVWithSunroofBuilderまたはBlueSUVWithSunroofBuilderを使用する代わりに、SUVWithSunroofBuilder（ "Red"）およびSUVWithSunroofBuilder（ "Blue"）を実行するビルダーパターンに適合していますか、それとも別のパターンに適合していますか？

私は最近、Joshua Bloch の『Effective Java』を読み始めました。Builder パターン [本書の項目 2] のアイデアは非常に興味深いものでした。プロジェクトに実装しようとしましたが、コンパイル エラーが発生しました。以下は、本質的に私がやろうとしていたことです：

複数の属性を持つクラスとそのビルダー クラス:

上記のクラスを使用しようとするクラス:

次のコンパイラ エラーが発生します。

effectivejava.BuilderPattern.NutritionalFacts.Builder を含む外側のインスタンスが必要です NutritionalFacts n = new NutritionalFacts.Builder(10).carbo(23).fat(1).build();

メッセージの意味がわかりません。説明してください。上記のコードは、ブロッホが著書で提案した例に似ています。

これは難しい質問ではありません。以下の 2 つの C++ コード スニペットのどちらが優れているかを知りたいだけです (読みやすさ vs. 長さ vs.ボイラープレート):

オプション1

オプション #2

私は個人的には最初のオプションを好みますが、それは私がコードの作成者であり、コードが何をするかを既に知っているためかもしれません (コードを知らない人にとっては混乱するかもしれません)。Entityオブジェクトではなくオブジェクトに焦点が合っていることを示しているためEntity::Builder（そして短いため）、私はそれが好きです。