我目前正在将一个包含大量意大利面条式遗留代码的大型应用程序重构为更结构化、更易于维护、最重要的是可测试的东西。我可以看到，显然将类依赖项注入其中，而不是将对象创建与业务逻辑混合在一起，这使得编写单元测试变得更加容易。
我已经阅读了关于“使用依赖注入不当导致的问题多于解决的问题”的评论。这到底是什么意思呢？对于如此复杂的措辞，依赖注入似乎是一个非常简单的概念。您如何滥用通过构造函数发送依赖项而不是在依赖类中实例化它们的想法？为什么后者会更可取？
我现在所能看到的是，它使得编写测试和模拟对象的隔离功能变得非常容易。当一个类有太多职责并直接指向需要重构的类时，这似乎也变得非常明显。如果我避免在我的 DI 容器以外的任何地方使用 new 关键字（核心 PHP 类除外），我是否会忘乎所以？
我不会担心依赖注入过度。您已经陈述了自己从采用它中看到的一些好处（可测试性，鼓励良好的设计重新分离关注点）。
我听到的对依赖注入（和 IoC）的批评是它会引入太多的复杂性。虽然由于糟糕的实现当然有可能使事情变得过于复杂，但我不同意这种抱怨是依赖注入的一个内在问题。
需要注意的是，您为依赖项选择了正确的抽象和间接级别，这将为您提供所需的灵活性。太多的间接级别会增加复杂性而没有任何价值，但我认为这是依赖注入的正交问题。
有关依赖注入的更多可能缺点，请参阅此相关问题:)
关于您在编辑之前包含在原始问题中的太多依赖项的问题：
有许多依赖项可能是代码异味，解决此问题的重点应该是：
听起来您已经通过遵循这些原则解决了部分问题。您应该已经查看了您的类是否实现了适当的抽象级别。例如，需要访问多个数据模型的类可能会受益于通过外观或存储库访问它们。