静的内部ビルダークラスを使用する利点

会社のコードガイドラインを作成する過程で、伸縮自在のコンストラクターではなく、Effective JavaのBuilderパターンを使用することをお勧めしました。

ただし、少し考えてみれば、よりエレガントなソリューションは、ビルダークラスを削除し、オプションの引数を持つ余分なコンストラクターを削除することです。

したがって、必要なパラメータを備えた1つのコンストラクタ、通常のゲッター/セッターを用意し、コードにコメントを付けます。実装するときは、yrオブジェクトの新しいインスタンスを作成してから、値を設定します。

私の当初の考えは、どのパラメーターがオプションであり、何が必要であるかに関する混乱を取り除くことから利益が得られるということでした。ただし、真の利点は、メソッドチェーン/流暢なインターフェイスを使用することから得られます。

IDEがレッグワークを実行できるため、新しいインスタンスをたくさん作成する場合や、多くの（15以上の）オプションパラメーターがある場合にも、ビルダーパターンには利点があります。しかし、静的内部クラスをコーディングする余分な時間の価値はありますか、ビルダーの使用をお勧めしますか、それとも時間の無駄ですか？

私は、有効で一貫したオブジェクトを作成するために必要なすべての必須値をコンストラクターが提供するというパターンに従う傾向があります。オプションの値については、セッターができるだけ使用されないように、最も一般的なデフォルトが何であるかを考えます。

オプション値がたくさんある、またはオプション値の大部分がデフォルトから変更される傾向にあることがわかった場合は、ビルダーパターン（静的内部ビルダーまたはその他の同様の設計）を使用します。

ジョシュは一般的にかなり良いアドバイスをします-私が彼について好きな最高のことは、トレンチからのアドバイスであることです-彼は彼がJavaの一部の設計で間違いを犯したことを認め、そして効果的なJavaは部分的に彼の「治療」の一種です話す:-)

JoF Blochのビルダーパターンは、GoFビルダーパターンとよく似ており、チェーンされたコンストラクターの長いリストなしで、多くのデフォルトデータを持つ不変オブジェクトを作成する方法を提供します。

「必要なパラメーターを持つ1つのコンストラクター、通常のゲッター/セッター」がある場合、オブジェクトは不変ではなくなります。すなわち。インスタンス化した後で、いつでも変更できます。

それがあなたにとって問題でないなら、そもそもBuilderパターンは決して必要ではありません。それが問題である場合、ソリューションに欠陥があります。