「パラメータが多すぎる」のは視覚的な問題ですか、それとも論理的な問題ですか。

よると、機能が受け入れるべきか、多くのパラメータにそこガイドラインはありますか？、メソッドにパラメータが多すぎてはいけません。ただし、いくつかの回答は、この問題はビルダーパターンによって解決できることを示唆しています。

Builder b=new Builder();
b.setParm1("a");
b.setParm2("b");
.
.
.
Obj obj=b.createObj();

または、単一のオブジェクトにパラメーターをカプセル化します。

ObjectParam op=new ObjectParam();
op.param1="a";
op.param2="b";
.
.
.
obj.f(op);

しかし、それが問題を解決するかどうかは疑わしいです。なぜなら、パラメーターをより適切な方法で（つまり：水平から垂直に）配置する方法だと思いますが、タスクがあまりにも多くのパラメーターに依存するという性質は変わりません。そして、パラメーターのチェーンをより見やすくしたい場合は、各パラメーターに次のような新しい行を使用できます。

https://softwareengineering.stackexchange.com/a/331680/248528

だから私の質問は、「パラメータが多すぎる」は視覚的な問題（コードの長い1行を読み取るのは難しい）ですか、それとも論理的な問題（タスクの性質はパラメータが多すぎるかによって異なり、分解する必要があります）ですか。それが視覚的な問題の詳細である場合、各パラメーターの新しい行で問題が解決されますか？

それは何よりもまず論理的な問題です（多くの場合、視覚的な問題も伴います）。これに対する間違った解決策は、視覚的な問題を改善することだけを試みることです

パラメータを単一のオブジェクトにカプセル化する[...]パラメータをより適切な方法で整列する（つまり、水平から垂直に）

オブジェクトにパラメータをカプセル化しても、5つのパラメータをのような意味のない名前で任意のコンテナに入れることを意味するのではありませんObjectParam。代わりに、パラメータグループをオブジェクトにカプセル化すると、新しい抽象化が作成されます（または既存の抽象化が再利用されます）。お気に入り

• 3つのパラメーター「X、Y、Z」をパラメーター「type of position」にカプセル化するPoint3D、または

• パラメータ「startDate、endDate」をオブジェクトにカプセル化する、DateIntervalまたは

• これらのパラメーターをグループ化documentTitle, documentText, authorしたオブジェクトのパラメーターをカプセル化Documentする

関係のあるメソッドに多くの無関係なパラメーターがあり、適切なグループ名を作成できない場合は、おそらくパラメーターが多すぎ、責任が多すぎます。

多くのパラメータをとるメソッドは、本質的には、構成よりも慣例とは逆のステップです。これは、適切なデフォルトを使用して、必要に応じて値を変更する機能を失うことなく、そのような呼び出しを簡素化することを中心としています。

つまり、柔軟性を失いたくないことは明らかですが、ほとんどすべてのパラメーターを動的に渡す必要はありません。かなり多くのパラメータが固定/静的になる可能性があります。例としてzipプログラムを取り上げます。はい、多分あなたは圧縮アルゴリズム、圧縮のレベル、タスク専用のCPUコアの数などを変更したいと思うかもしれません。重要なのは、zipファイルを作成する必要があるたびにこれらのすべてのパラメーターを指定する必要がないため、必要不可欠なもの（つまり、宛先zipファイル名、zipファイルに追加するファイル）を提供することで呼び出しを効果的に削減することです。

構成アプローチよりも慣例を使用する理由は、多くのパラメーターを必要とするメソッドを用意してはならないのと同じ理由です。要するに、シンプルさは良いです。