依赖注入总是正确的答案吗？

Question

我目前正在考虑很多关于依赖注入的问题，它有利有弊。一般而言，似乎一致认为在大多数情况下依赖注入是正确的选择。我看到了它的用处以及它如何使代码更具可读性。因此，我试图用尽可能多的依赖注入来创建我的类，将关注点分成多个对象。在我 70% 的日常工作中，这很好。它有效，我看到了好处。

然而，剩下的 30% 让我有些挣扎。我对依赖注入本身的概念没有问题，但事实上我认为 PHP 确实有一些“特殊属性”，这让我怀疑依赖注入是正确的选择。

1. 主要观点似乎是使用 DI 而不是服务定位器的优点，假设您有“编译时错误”而不是“运行时错误”。我明白，对于 Java 或 C 之类的语言，但 PHP 中没有“编译时错误”这样的东西不会自动导致“运行时错误”。至少我没有遇到过。

2. 在启动一次的程序中，将它们的源加载到内存中并在它们被执行时一直保持在那里，我明白你为什么要使用 DI。这是有道理的，您不必（通常）担心应用程序需要多长时间才能达到运行状态，并且您应该（通常）有足够的内存来保存所有代码。所以加载所有依赖项并将它们保存在内存中似乎没问题。但是，PHP 脚本在 Apache、NGINX 或其他上下文中使用时，每次用户访问时都会启动。除此之外，我们希望我们的应用程序运行得尽可能快，用尽可能少的资源来充分利用服务器硬件。问题是，如果我每次都加载整个库，即使我只访问了一小部分代码，这似乎也很浪费......（我在下面有一个例子来说明我的意思）

3. 如上所述，我尝试尽可能多地使用 DI。但是剩下的 30% 我仍然使用服务定位器模式来处理，因为我 a.) 只需要在特定条件下的依赖项或 b.) 我访问一个或多或少可以用全局函数替代的服务/助手类。（见下例）

在这方面，我阅读了很多关于 a.) 助手类是邪恶的 b.) 当您在类中只使用一次依赖项时，您应该将其拆分为一个单独的类（老实说，这是我不知道的一点完全明白，因为当您使用 DI 时，您无论如何都必须创建该类，那么为什么要将它与一般类分开？）。

我创建了一些虚拟代码来展示我认为（在撰写本文时）服务定位器（在 PHP 中）比 DI 更明智的 30%。

Answer 1

没有模式总是答案；当这些不能被推迟时，做出明智的、务实的架构决策很重要。您说得对，在 PHP 的情况下，由于必须在每个请求上实例化整个对象图，DI 可能会导致性能损失。然而，依赖注入显然与性能无关。它是一种实现控制反转的方法，最终走向模块化设计、关注点分离、可重用性和可测试性。这些好处大大超过了“编译时”错误捕获能力。在软件项目的早期阶段，预测它是否足够简单（你的 30%）以放弃所有这些好处并采用互连设计而不是模块化设计是非常困难和冒险的。部件紧密耦合，只是名称或性能。