一部のプロジェクトでは、チェーンを下っていくときにパラメーターを追加するクラス階層があります。下部では、一部のクラスは最大30個のパラメーターを持つことができ、そのうち28個はスーパーコンストラクターに渡されます。
Guiceのようなものを通じて自動化されたDIを使用することは良いことだと認めますが、いくつかの技術的な理由により、これらの特定のプロジェクトはJavaに制限されています。
タイプごとに引数をアルファベット順に整理する規則は機能しません。タイプがリファクタリングされた場合（引数2に渡した円がシェイプになったため）、突然順序が乱れる可能性があるためです。
この質問は、「それが問題である場合は、設計レベルで間違っている」という特定の批判に関係している可能性がありますが、私は任意の視点を探しています。
回答:
Builderデザインパターンが役立つ場合があります。次の例を考えてみましょう
public class StudentBuilder
{
private String _name;
private int _age = 14; // this has a default
private String _motto = ""; // most students don't have one
public StudentBuilder() { }
public Student buildStudent()
{
return new Student(_name, _age, _motto);
}
public StudentBuilder name(String _name)
{
this._name = _name;
return this;
}
public StudentBuilder age(int _age)
{
this._age = _age;
return this;
}
public StudentBuilder motto(String _motto)
{
this._motto = _motto;
return this;
}
}
これにより、次のようなコードを記述できます
Student s1 = new StudentBuilder().name("Eli").buildStudent();
Student s2 = new StudentBuilder()
.name("Spicoli")
.age(16)
.motto("Aloha, Mr Hand")
.buildStudent();
必須フィールドを省略すると（おそらく名前は必須です）、Studentコンストラクターに例外をスローさせることができます。また、これらの呼び出しの順序は同じように機能するため、引数の順序を追跡する必要なく、デフォルト/オプションの引数を使用できます。
buildStudent()メソッドに例外をスローさせました。
関連するパラメーターをオブジェクト内にカプセル化できますか？
たとえば、パラメータが
MyClass(String house, String street, String town, String postcode, String country, int foo, double bar) {
super(String house, String street, String town, String postcode, String country);
this.foo = foo;
this.bar = bar;
それからあなたは代わりに持つことができます：
MyClass(Address homeAddress, int foo, double bar) {
super(homeAddress);
this.foo = foo;
this.bar = bar;
}
おそらくあなたがしたいことはビルダークラスを持っていることです。次に、次のようなことを行います。
MyObject obj = new MyObjectBuilder().setXxx(myXxx)
.setYyy(myYyy)
.setZzz(myZzz)
// ... etc.
.build();このJosh Blochプレゼンテーション（PDF）の8ページ目以降、またはこの「効果的なJava」のレビューを参照してください。
まあ、ビルダーパターンの使用は1つのソリューションかもしれません。
しかし、20〜30個のパラメーターに到達すると、パラメーター間に高い関係があると思います。したがって、（提案されているように）それらを論理的に健全なデータオブジェクトにラップすることはおそらく最も理にかなっています。このようにして、データオブジェクトはパラメータ間の制約の有効性をすでに確認できます。
過去のすべてのプロジェクトで、パラメータが多すぎると（28ではなく8になりました）、より適切なデータモデルを作成することでコードを無害化することができました。
Java 1.4に制約されているため、DIが必要な場合は、Springが非常に適切なオプションになります。DIは、コンストラクターパラメーターがサービスまたは実行時に変化しないものである場所でのみ役立ちます。
オブジェクトの作成方法に可変オプションが必要なために、これらの異なるコンストラクターがすべてある場合は、Builderパターンの使用を真剣に検討する必要があります。
ビルダーパターンを使用する場合は、ImmutablesまたはPOJOBuilderを使用することをお勧めします。