我目前正在考虑很多关于依赖注入的问题，它有利有弊。一般而言，似乎一致认为在大多数情况下依赖注入是正确的选择。我看到了它的用处以及它如何使代码更具可读性。因此，我试图用尽可能多的依赖注入来创建我的类，将关注点分成多个对象。在我 70% 的日常工作中，这很好。它有效，我看到了好处。
然而，剩下的 30% 让我有些挣扎。我对依赖注入本身的概念没有问题，但事实上我认为 PHP 确实有一些“特殊属性”，这让我怀疑依赖注入是正确的选择。
主要观点似乎是使用 DI 而不是服务定位器的优点，假设您有“编译时错误”而不是“运行时错误”。我明白，对于 Java 或 C 之类的语言，但 PHP 中没有“编译时错误”这样的东西不会自动导致“运行时错误”。至少我没有遇到过。
在启动一次的程序中，将它们的源加载到内存中并在它们被执行时一直保持在那里，我明白你为什么要使用 DI。这是有道理的，您不必（通常）担心应用程序需要多长时间才能达到运行状态，并且您应该（通常）有足够的内存来保存所有代码。所以加载所有依赖项并将它们保存在内存中似乎没问题。但是，PHP 脚本在 Apache、NGINX 或其他上下文中使用时，每次用户访问时都会启动。除此之外，我们希望我们的应用程序运行得尽可能快，用尽可能少的资源来充分利用服务器硬件。问题是，如果我每次都加载整个库，即使我只访问了一小部分代码，这似乎也很浪费......（我在下面有一个例子来说明我的意思）
如上所述，我尝试尽可能多地使用 DI。但是剩下的 30% 我仍然使用服务定位器模式来处理，因为我 a.) 只需要在特定条件下的依赖项或 b.) 我访问一个或多或少可以用全局函数替代的服务/助手类。（见下例）
在这方面，我阅读了很多关于 a.) 助手类是邪恶的 b.) 当您在类中只使用一次依赖项时，您应该将其拆分为一个单独的类（老实说，这是我不知道的一点完全明白，因为当您使用 DI 时，您无论如何都必须创建该类，那么为什么要将它与一般类分开？）。
我创建了一些虚拟代码来展示我认为（在撰写本文时）服务定位器（在 PHP 中）比 DI 更明智的 30%。
收到一只叮咚