依赖注入如何不仅将复杂性移到一个单独的类中？

我本周一直在研究使用Typhoon框架进行依赖注入。我了解到，分离对象的构造对于在单元测试期间用模拟替换任意组件是有好处的，到目前为止，我仅从中看到了好处。

但是我不禁想到，在我拥有一个包含数十个头导入的庞大的视图控制器类之前，现在我有了一个包含数十个头导入的庞大的工厂类。我应该避免参加大量的工厂培训班吗？

依赖注入简单地帮助定义一个对象如何知道另一个依赖对象。它不会帮助您降低系统的整体复杂性。如果在DI之前需要数十次导入，则在DI之后仍需要数十次导入。不同之处在于这些导入将位于更有意义的位置（类）（工厂，制造商等）。

通过允许通过构造函数或方法提供依赖关系，可以让您自己灵活地为您的类提供一个不同但仍有效的依赖对象，并通过消除担忧来提高该类的凝聚力。

有几种相似且经常一起使用的原理：依赖注入（DI），控制反转（IoC）和依赖反转原理（DIP）

从本文 http://martinfowler.com/articles/dipInTheWild.html

DI与布线有关，IoC与方向有关，DIP与形状有关

依赖注入不会降低复杂性，但是会通过关注点分离和减少耦合来提高可操作性。

但是我不禁想到，在我拥有一个包含数十个头导入的庞大的视图控制器类之前，现在我有了一个包含数十个头导入的庞大的工厂类。我应该避免参加大量的工厂培训班吗？

您应该避免使用“笨拙的”课程。因此，假设您将视图控制器分为较小的，更易于维护的类。现在，所有这些人都有责任掌握其依赖关系。DI帮助您将依赖关系管理从所有这些类移到仅负责依赖关系管理的工厂/配置类中-请参阅“单一职责原则”。尽管它肯定会比原始的视图控制器少很多，但如果它变得太大，您总是可以选择将其拆分为较小的依赖项管理类，这些类负责应用程序的不同部分。

用外行的话来说：

依赖注入将复杂性移到危害较小的地方。

@gnat的编辑：DI不仅将复杂性转移到一个单独的类中，还将其转移到造成较小危害的地方。