関数の引数の数を最小化する手法

クリーンコードでは、「関数の引数の理想的な数はゼロ」と書かれています。理由は説明されており、理にかなっています。私が望んでいるのは、この問題を解決するために4つ以上の引数を持つメソッドをリファクタリングする手法です。

1つの方法は、引数を新しいクラスに抽出することですが、それは確かにクラスの爆発につながりますか？そして、それらのクラスは、いくつかの命名規則に違反する名前で終わる可能性が高い（「データ」または「情報」などで終わる）？

別の手法は、複数の関数で使用される変数をプライベートメンバー変数にして、それらを渡さないようにすることですが、変数のスコープを拡張し、おそらく実際にそれを必要としない関数に対して開かれるようにします。

関数の引数を最小化する方法を探し、それを行うのが良い考えである理由を受け入れました。

覚えておくべき最も重要なことは、それらがルールではなくガイドラインであることです。

メソッドが単に引数を取る必要がある場合があります。+たとえば、数字の方法を考えてください。または、addコレクションのメソッド。

実際には、1でも、それは2つの数値を追加するために何を意味するのかℤで例えば、文脈に依存していると主張するかもしれません3 + 3 == 6が、ℤ中_{| 5} 3 + 3 == 2ので、本当に加算演算子はかかるコンテキストオブジェクトのメソッドでなければなりません2 Aの引数を代わりに1つの引数を取る数値のメソッド。

同様に、2つのオブジェクトを比較するメソッドは、一方をもう一方を引数として取るメソッド、または2つのオブジェクトを引数として取るコンテキストのメソッドのいずれかでなければならないため、単に比較メソッドを使用するのは意味がありません引数が1つ未満。

そうは言っても、メソッドの引数の数を減らすためにできることがいくつかあります。

• メソッド自体を小さくします。たぶん、メソッドがそのような多くの引数を必要とする場合、それはやりすぎです？
• 欠落している抽象化：引数が密接に相関している場合、おそらくそれらは一緒に属していて、欠落している抽象化がありますか？（正規のテキストブックの例：2つの座標の代わりにPointオブジェクトを渡すか、ユーザー名とメールを渡す代わりにオブジェクトを渡しIdCardます。）
• オブジェクト状態：複数のメソッドで引数が必要な場合、オブジェクト状態の一部である可能性があります。一部のメソッドでのみ必要であり、他のメソッドでは必要でない場合、オブジェクトが多すぎて、実際には2つのオブジェクトである必要があります。

1つの方法は、引数を新しいクラスに抽出することですが、それは確かにクラスの爆発につながりますか？

ドメインモデルにさまざまな種類のものがある場合、コードはさまざまな種類のオブジェクトになります。それには何の問題もありません。

そして、それらのクラスは、いくつかの命名規則に違反する名前で終わる可能性が高い（「データ」または「情報」などで終わる）？

適切な名前が見つからない場合は、多すぎる引数をグループ化したか、少なすぎます。そのため、クラスのフラグメントだけがあるか、複数のクラスがあります。

別の手法は、複数の関数で使用される変数をプライベートメンバー変数にして、それらを渡さないようにすることですが、変数のスコープを拡張し、おそらく実際にそれを必要としない関数に対して開かれるようにします。

すべてが同じ引数で動作するメソッドのグループとそうでないメソッドのグループがある場合、それらは異なるクラスに属している可能性があります。

「たぶん」という言葉の使用頻度に注意してください。それがルールではなくガイドラインである理由です。たぶん、4つのパラメーターを使用したメソッドはまったく問題ありません！

オブジェクトは暗黙的な引数であるため、引数がゼロであることは副作用を意味しないことに注意してください。いくつのゼロアリティメソッドを見るたとえば、Scalaの不変リストに含まれる。

私が「レンズフォーカシング」テクニックと呼ぶ便利なテクニックの1つです。カメラレンズの焦点を合わせるとき、遠くに移動して正しいポイントに戻すと、真のフォーカスポイントが見やすくなります。ソフトウェアリファクタリングについても同じことが言えます。

特に、分散バージョン管理を使用している場合、ソフトウェアの変更は簡単に試してみて、見た目が好きかどうかを確認し、気に入らない場合は元に戻してください。

あなたの現在の質問の文脈では、それは最初にいくつかの分割された関数でゼロまたは1つの引数バージョンを書くことを意味し、次に読みやすくするためにどの関数を組み合わせる必要があるかを比較的簡単に見ることができます。

作者はテスト駆動開発の大擁護者でもあることに注意してください。これは、ささいなテストケースから始めるため、最初は低アリティ関数を生成する傾向があります。

関数への引数の数を減らすことを単純に（そして単純に-または盲目的に言うべきです）アプローチは、おそらく間違いではありません。多数の引数を持つ関数には何も問題はありません。ロジックで必要な場合、それらは必要です...長いパラメーターリストは、読みやすくするために適切にフォーマットされ、コメント化されている限り、まったく心配しません。

全てまたは引数のサブセットが1つの独特の論理エンティティに属し、一般的に、あなたのプログラム全体のグループに回された場合には、それは多分、一般的に構造体や他のオブジェクト-いくつかのコンテナにグループ彼らに意味があります。典型的な例は、ある種のメッセージまたはイベントデータタイプです。

そのアプローチを簡単にやり直すことができます-そのようなトランスポートコンテナーとの間で荷物の梱包と開梱が読みやすさを向上させるよりも多くのオーバーヘッドを生成することがわかったら、おそらく行き過ぎです。

OTOH、大きなパラメーターリストは、プログラムが適切に構造化されていないことを示している可能性があります-そのような多数のパラメーターを必要とする関数は、多すぎることを試みているため、いくつかの小さな関数に分割する必要があります。パラメータの数を心配するよりも、ここから始めたいと思います。

魔法の方法はありません。正しいアーキテクチャを発見するには、問題の領域をマスターする必要があります。それがリファクタリングの唯一の方法です。問題のあるドメインをマスターすることです。4つ以上のパラメーターは、現在のアーキテクチャに障害があり、間違っていることを確実に示しています。

唯一の例外はコンパイラ（メタプログラム）とシミュレーションです。制限は理論的には8ですが、おそらく5だけです。