Php 依赖注入过多？

我目前正在将一个包含大量意大利面遗留代码的大型应用程序重新分解为更结构化、更易于维护、最重要的是可测试的应用程序。我可以看到，很明显，将类依赖项注入到它们中，而不是将对象创建与业务逻辑相混合，这使得编写单元测试更加容易

我读过一些评论，大意是“不恰当地使用依赖注入导致的问题多于它所解决的问题”。这到底意味着什么？对于如此复杂的措辞，依赖注入似乎是一个相当简单的概念。如何滥用通过构造函数发送依赖项而不是在依赖类中实例化依赖项的想法？为什么后者更可取

---

现在我所能看到的是，它使编写测试和模拟对象的隔离功能变得非常容易。当一个类有太多的职责并且直接指向需要重构的类时，这似乎也让它变得非常明显。如果我在我的DI容器之外的任何地方避免使用新关键字（核心PHP类除外），我是否会被冲昏头脑呢？

我不会担心依赖项注入太过火。您已经说明了您从采用它中看到的一些好处（测试能力，鼓励良好的设计重新分离关注点）

我听到过对依赖注入（和IoC）的批评，认为它会引入太多的复杂性。虽然由于糟糕的实现可能会使事情变得过于复杂，但我不能同意这种抱怨，因为它是依赖注入的一个固有问题

需要注意的是，您为依赖项选择了适当的抽象和间接层次，这将为您提供所需的灵活性。太多的间接层次会毫无价值地增加复杂性，但我认为这是依赖注入的一个正交问题

有关依赖项注入的更多可能缺点，请参阅：）

---

关于编辑前原始问题中包含的依赖项过多的问题：

有许多依赖关系可能是一种代码味道，解决这一问题的重点应该是：

• 以及

听起来你已经通过遵循这些原则解决了部分问题。 您应该已经了解了类是否实现了适当的抽象级别。 例如，需要访问多个数据模型的类可能会受益于通过门面或接口访问它们