依存関係の注入：コンテナを注入しないのはなぜですか？

依存噴射における肥大化したコンストラクターのタックル

この例のように、

過度に複雑なコンストラクターの署名：

<code>public MyClass(Container con, SomeClass1 obj1, SomeClass2 obj2, ... )</code>

は一般的な問題です。 すべてのクラスに直接コンテナ（Container con）を注入してみませんか？ これにより、コンストラクターが大幅に簡素化されますが、重大な欠点があります。 それは基本的に容器を栄光の静的工場に変えます。

栄光の統計と制御の反転の問題（IOC）

コンテナをサービスロケーターとして使用すると、グローバルな静的アクセスポイントのように動作します。これは単一の責任の原則に違反し、テストと保守性をより困難にします。 クラスは、コンテナの実装に密接に結合され、柔軟性と再利用性を妨げます。

ファサードサービスを使用したリファクタリング

コンストラクターインジェクションの強度は、単一の責任原則の違反を強調する能力にあります。 コンストラクターが扱いにくいとき、それはリファクタリングの明確な信号です。 ソリューションには、多くの場合、ファサードサービスの作成が含まれます

ファサードサービスでは、より高レベルでより抽象的なインターフェイスを導入します。このインターフェイスは、多数の細かい依存関係と相互作用する複雑さを隠しています。 これにより、よりクリーンで管理しやすいコードが促進され、テスト可能性が向上します

以上が依存関係の注入：コンテナを注入しないのはなぜですか？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。