Javaで大きなコンストラクターを分割する方法に関するこの質問を読みました。しかし、私は自分の場合に何をすべきかよくわかりません。質問は、ビルダーパターンがより良い方法であることを示唆していますが、同時に、あるサブセンテンスの 1 人が「いくつかのパラメーターがオプションである場合のみ」と言っていました。すべてのパラメーターが必須であるため、ビルダー パターンの利点は見当たりません。重要な情報の平和を渡すのを忘れる危険を冒すだけです。したがって、新しい論理グループ化オブジェクトを作成する唯一のオプションですか、それともビルダー パターンに関するいくつかの重要な事実が欠けていますか? 物が欠けている可能性がある場合にのみ、ビルダーは良いように見えますか?
3 に答える
2
「したがって、新しい論理グループ化オブジェクトを作成する唯一のオプションですか、それともビルダー パターンに関する重要な事実を見逃しているのでしょうか?」
私の意見は：
はい。この場合ビルダーを使用しても、抽象化に必要な作業量と比較して、追加の利点はありません。
コメントにも記載されています。オブジェクトのパラメーターが多すぎる場合は、オブジェクトがやりすぎている可能性があります。
于 2012-01-09T03:06:50.663 に答える
0
すべてのパラメーターが必須である場合でも、ビルダー パターンにはいくつかの利点があります。
それはより読みやすいです。コンストラクターに 10 個のパラメーターがある場合、特にパラメーターの多くが 0 または null の場合、どれがどれであるかを覚えるのは困難です。
ビルダーは、必要なデータを蓄積するためにいくつかの異なるメソッドに渡すことができます。これは、そのデータの一部が 1 つのクラスに存在し、一部が別のクラスに存在する場合に役立ちます。
パラメーターの一部が、コンストラクターに渡す前にアセンブルする必要があるリストまたはその他のコレクションである場合、ビルダーはそれを内部的に処理できます。また、ビルダーはこれらのオブジェクトのいずれもリークしないことを認識しているため、防御コピーの必要性を一部排除することもできます。
ビルダーはシリアライゼーション プロキシとして機能し、オブジェクトのシリアライズされた形式または JAXB XML 形式をより詳細に制御できます。
とは言うものの、私のアプローチは常に単純なコンストラクターから開始し、そのコンストラクターを呼び出すとコードに多くの混乱が生じ、ビルダーによって追加された余分な明確さがまったく新しいクラスを追加することを正当化するのに十分な場合にのみ、ビルダーを導入することです。 .
于 2012-01-09T03:13:12.450 に答える
0
コンストラクターへの多くのパラメーターは、クラスが扱う懸念事項が多すぎることを示している可能性もあります。ビルダーは、カスケードされたケースがある場合にのみ意味があります。男の子の場合は失礼な言葉のセクションを追加し、女の子の場合は買い物リストを追加します。
懸念の分割は、継承、ジェネリック パラメータ化クラス、委譲クラス、およびより重い論理グループ化オブジェクトのいずれかに依存します。
テストケースを書けるかどうかも検討してください。ここでは、テスト駆動開発が役に立ちます。その後、パラメーター クラスをモックする必要がある場合、「依存性注入」にはより抽象的なパラメーター クラスが必要になります。
于 2012-01-09T03:23:30.507 に答える