依存性注入は、複雑さを別のクラスに移動するだけではどうですか？

今週は、依存関係注入のためにTyphoonフレームワークを使用することを検討してきました。オブジェクトの構造を分離することは、単体テスト中に任意のコンポーネントをモックに置き換えるのに有益であることがわかりました。

しかし、何十ものヘッダーがインポートされた巨大なビューコントローラークラスがあった前に、何十ものヘッダーがインポートされた巨大なファクトリークラスができたと考えざるを得ません。大規模なファクトリークラスを避けるべきですか？

依存性注入は、あるオブジェクトが別の依存オブジェクトをどのように認識するかを定義するのに役立ちます。システム全体の複雑さを軽減するのには役立ちません。DIの前に数十のインポートが必要だった場合でも、後で数十のインポートが必要になります。違いは、これらのインポートがより意味のある場所（クラス）（工場、ビルダーなど）にあることです。

コンストラクターまたはメソッドを介して依存関係を提供できるようにすることで、異なるがまだ有効な依存オブジェクトをクラスに提供し、懸念事項を取り除くことによってそのクラスの結束力を高める柔軟性を自分で実現できます。

類似していて、一緒に使用されることが多いいくつかの原則があります。依存性注入（DI）、制御の反転（IoC）、および依存性反転の原則（DIP）

この記事から http://martinfowler.com/articles/dipInTheWild.html

DIは配線について、IoCは方向について、DIPは形状についてです

依存性注入は複雑さを軽減しませんが、関心事の分離と結合の減少により操作性を向上させます。

しかし、何十ものヘッダーがインポートされた巨大なビューコントローラークラスがあった前に、何十ものヘッダーがインポートされた巨大なファクトリークラスができたと考えざるを得ません。大規模なファクトリークラスを避けるべきですか？

「巨大な」クラス、期間は避けてください。したがって、View Controllerをより小さく、より保守しやすいクラスに分割するとします。現在、それらすべてが依存関係を把握する責任があります。DIは、この依存関係管理を、これらすべてのクラスから、依存関係管理のみを担当するファクトリー/構成クラスに移動するのに役立ちます。単一責任の原則を参照してください。また、元のビューコントローラーよりもはるかに「面倒」ではありませんが、大きくなりすぎた場合は、常に、アプリケーションのさまざまな部分を担当する小さな依存関係管理クラスに分割することができます。

素人の言葉で：

依存性注入は、複雑さを害の少ない場所に移動します。

@gnatの編集：DIは、複雑さを別のクラスに移動するだけでなく、害の少ない場所に移動します。