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