したがって、10個のオブジェクトがあり、それぞれに1〜3個の依存関係があります（緩い結合に関する限り、これは問題ないと思います）が、動作（タイムアウト、ウィンドウサイズなど）を定義するために使用できるいくつかの設定もあります。
制御の反転コンテナの使用を開始する前に、コンストラクターのサイズを推奨される「4未満」パラメーターに維持するために、複数の設定を必要とする各オブジェクトのファクトリと、場合によっては単純なObjectSettingsオブジェクトを作成していました。サイズ。私は現在、制御の反転を使用していますが、それに対するポイントはあまりわかりません。確かに、7つのパラメーターを持つコンストラクターを取得する可能性がありますが、誰が気にしますか？とにかく、それはすべてIoCによって記入されています。
私はここで何かが欠けていますか、それともこれは基本的に正しいですか？
クラスの複雑さと IoC コンストラクターのサイズとの関係は、この質問を読むまでは思いつきませんでしたが、以下の私の分析では、IoC コンストラクターに多くの引数があることは、IoCを使用するときに注意すべきコードの匂いであることが示唆されています。短いコンストラクター引数リストに固執するという目標を持つことは、クラス自体を単純に保つのに役立ちます。単一責任の原則に従うことで、この目標に向けて進むことができます。
現在、Spring.NET フレームワークを使用してインスタンス化された 122 個のクラスを持つシステムで作業しています。これらのクラス間のすべての関係は、コンストラクターで設定されます。確かに、このシステムには、私がいくつかのルールを破った完全ではないコードがかなりの割合で含まれています。（でもね、私たちの失敗は学ぶチャンス！）
これらのクラスのコンストラクターにはさまざまな数の引数があり、それを下の表に示します。
Number of constructor arguments Number of classes
0 57
1 19
2 25
3 9
4 3
5 1
6 3
7 2
8 2
引数がゼロのクラスは、具体的な戦略クラス、またはデータを外部システムに送信することによってイベントに応答するクラスのいずれかです。
5 つまたは 6 つの引数を持つものはすべてやや洗練されておらず、リファクタリングを使用して単純化できます。
7 つまたは 8 つの引数を持つ 4 つのクラスは、神のオブジェクトの優れた例です。それらは分割する必要があり、それぞれがシステム内のトラブルスポットのリストに既に含まれています.
残りのクラス (1 ～ 4 個の引数) は (ほとんどの場合) シンプルに設計されており、理解しやすく、単一責任の原則に準拠しています。
多くの依存関係（おそらく8を超える）の必要性は、設計上の欠陥を示している可能性がありますが、一般に、設計がまとまりがある限り問題はないと思います。
また、コンストラクターの引数を乱雑にするのではなく、ロギングや承認などのインフラストラクチャの問題にサービスロケーターまたは静的ゲートウェイを使用することを検討してください。
編集：8は多分多すぎますが、私はそれの奇妙なケースがあるだろうと思いました。私が同意するリーの投稿を見た後、1-4は通常良いです。
これは難しい問題であり、適切なプロパティが可変であり、不変のプロパティと有用なデフォルトのない必要な依存関係のみがコンストラクターの一部であるハイブリッドアプローチを好む理由です。一部のクラスは必需品で構成され、必要に応じてセッターを介して調整されます。
ジョージ、
まず、オブジェクト間の依存関係は何ですか?
「いさ」関係が多い？ハサ関係が多い？
ファンインが多い？それともファンアウト？
ジョージの反応: 「ほとんどは、継承のアドバイスよりもコンポジションに従おうとしてきました...なぜそれが問題になるのでしょうか?」
ほとんど「はさ」なので大丈夫です。
ただし、メモリリークを防ぐために、コンポーネントの構築 (および破棄) が正しく行われていることを確認してください。
また、これが C++ の場合は、必ず仮想デストラクタを使用してください。
それはすべて、IOC を実行するために使用したコンテナーの種類と、インスタンス化するオブジェクトを飽和させるためにコンテナーが注釈または構成ファイルを使用するかどうかに応じて異なります。さらに、コンストラクターのパラメーターが単純なプリミティブ データ型である場合、それは実際には大したことではありません。ただし、非プリミティブ型の場合、私の意見では、コンストラクター ベースの DI ではなく、プロパティ ベースの DI を使用できます。