私のクラスには次のコンストラクタがあります
public MyClass(File f1, File f2, File f3, Class1 c1, Class2 c2, Class3 c3)
{
..........
}
ご覧のとおり、6 つのパラメーターがあります。このコードを見て、先輩の 1 人が、6 つのパラメーターを渡す代わりに、構成オブジェクトを渡すほうがよいと言いました。
私がこのようにコードを書いたのは、最近「依存性注入」について読んだことがあるからです。したがって、構成オブジェクトを渡すことは原則に反すると思います。
「依存性注入」の私の解釈は正しいですか? または先輩のアドバイスに従うべきですか？
「構成オブジェクト」は、この状況で適用される鈍い用語です。それは純粋に機械的な意味であなたの努力を組み立てます。目標は、クラスの消費者にあなたの意図を伝えることです。それに向けてリファクタリングしましょう。
多数のパラメーターを持つメソッドまたはコンストラクターは、それらの間の関係が緩いことを示しています。消費者は通常、APIを理解するためにより多くの推論を行う必要があります。これらの3つのクラスと一緒にこれらの3つのファイルの何が特別ですか？それは伝達されていない情報です。
これは、暗黙の概念から明示的な概念を抽出することにより、より意味のある意図を明らかにするインターフェースを作成する機会です。たとえば、3つのファイルがユーザーのために関連している場合、UserFileSetパラメーターはそれを明確に表します。おそらく、、、およびにf1関連しています。これらの関連付けを独立したクラスとして宣言すると、パラメーター数が半分になり、APIから取得できる情報の量が増えます。c1f2c2f3c3
最終的に、リファクタリングは問題のドメインに大きく依存します。パラメータリストを満たすために単一のオブジェクトを作成する必要があると思い込まないでください。パラメータ間の関係の輪郭に沿ってリファクタリングしてみてください。これにより、解決に使用された言語よりも、解決する問題を反映したコードが常に生成されます。
構成オブジェクトを使用することは、依存性注入パターンを使用することと矛盾するとは思いません。それは、依存関係を注入する形式と、20 個のパラメーターを受け取る関数 (この場合はコンストラクター) を使用する方がよいか、それらのパラメーターをクラスに結合してバンドルする方がよいかという一般的な問題です。
依存性注入を自由に使用できます。つまり、ファクトリまたはコンテナーによって構成オブジェクトを構築し、クラスのインスタンスを作成するときにコンストラクターに注入します。それが良いアイデアであるかどうかは、特定のケースにもよりますが、特効薬はありません;)