依赖注入过多？

Question

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

我读过 cmets，大意是“不正确地使用依赖注入会导致比它解决的问题更多的问题”。这到底是什么意思呢？对于如此复杂的措辞，依赖注入似乎是一个非常简单的概念。您如何滥用通过构造函数发送依赖项而不是在依赖类中实例化它们的想法？为什么后者会更可取？

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

Answer 1

我不会担心依赖注入过度。您已经说明了采用它所带来的一些好处（可测试性、鼓励良好的设计重新分离关注点）。

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

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

请参阅this related question 了解依赖注入的更多可能缺点：)

---

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

有许多依赖项可能是代码异味，解决此问题的重点应该是：

• single responsibility principle，和
• separation of concerns

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