web-dev-qa-db-ja.com

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

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

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行を読み取るのが難しい）ですか、それとも論理的な問題（タスクの性質はパラメータが多すぎるかによって異なり、分解する必要があります）ですか。それが視覚的な問題の詳細である場合、各パラメーターの新しい行で問題が解決されますか？

coding-styleparameters
8
ocomfd

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

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

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

  • 3つのパラメーター「X、Y、Z」をパラメーター「型の位置Point3D、または

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

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

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

24
Doc Brown

多くのパラメータを取るメソッドは、本質的に、 構成上の規約 アプローチとは逆方向のステップです。これは、賢明なdefaults。

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

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

1
Neil