核心要点
许多程序员（包括我自己，所以这是我公开的 mea culpa）认为控制反转 (IoC) 不过是依赖注入 (DI) 的同义词。这种想法有一个相当直观的原因：如果DI 的目的是促进类的设计，使其外部协作者由周围环境提供，而不是反过来查找它们，那么这个过程可以有效地被视为一种IoC 的形式。但是，虽然 DI = IoC 这个等式通常有效，但控制反转的概念本身实际上要广泛得多。事实上，可以说 DI 是一个利用 IoC 优势的特定用例，但它远非唯一的一个。这让我们回到起点；如果 DI 只是一种依赖 IoC 优势的模式，那么 IoC 究竟是什么呢？传统上，应用程序组件被设计为操作和控制执行环境，这种方法在某种程度上运行良好。例如，可以实现一个日志记录模块来将数据记录到文件中，以及如何以及何时记录数据完全由模块控制。日志文件（在这种情况下是环境的一部分）只是一个外部的、被动的元素，不会影响模块的工作方式。但是，假设我们需要扩展模块的功能，并使其能够额外地将数据记录到数据库，或者最终甚至通过电子邮件。升级模块以公开额外功能将使其复杂性增加，随着处理这些额外任务所需的逻辑打包在相同的 API 后面，它会变得越来越臃肿。这种方法有效，但根本无法扩展。这种情况可以通过一种相当简单的方式解决。与其让模块完全负责将数据记录到多个端点，我们可以将责任直接转移到外部环境。模块的实现将保持非常简单，仅限于充当简单的事件调度器。另一方面，环境将负责实现将数据记录到与所讨论的模块完全独立的端点所需的所有逻辑。毫不奇怪，在组件和环境之间反转这些责任的过程正式被称为控制反转（或者在更轻松的术语中，好莱坞原则），并且在开发可扩展的、高度解耦的程序模块时，它的实现可以是一个真正的提升。当然，IoC 是一种与语言无关的范例，因此可以在 PHP 世界中轻松使用它。
实现控制反转——观察领域对象
IoC 的确无处不在，因此很容易找到它的生产实现。首先想到的用例是依赖注入，但还有许多其他同样具有代表性的用例，尤其是在事件驱动设计的领域。如果您想知道 IoC 在何种平行宇宙中与事件处理机制协同工作，请考虑 GoF 库中的一个经典案例：观察者模式。观察者几乎在任何地方都被使用，甚至通过 JavaScript 在客户端使用，它们是 IoC 概念的突出示例；有一个高度解耦的主体专注于执行少数狭窄的任务，而不会污染周围环境，而一个或多个外部观察者负责实现处理主体触发的事件所需的逻辑。如何处理事件，甚至处理新事件，完全是观察者的责任，而不是主体的责任。一个例子可能是一种让我的先前冗长说法更清晰的好方法。因此，假设我们已经实现了一个原始的领域模型，它定义了博客文章和评论之间的一对多关系。在这种情况下，我们将故意雄心勃勃，并使模型能够发送电子邮件以在将新评论添加到帖子时通知系统管理员。老实说，在不诉诸 IoC 的情况下实现这样的功能实际上将是一团糟，因为我们将要求领域对象做一些超出其范围的事情。相反，我们可以采用基于 IoC 的方法并定义如下领域类：
（此处省略了代码示例，因为这部分内容与问题要求的伪原创和保持图片格式无关，且篇幅过长。）
将控制委托给外部环境——实现评论通知服务
构建一个能够在向博客文章添加新评论时触发电子邮件通知的观察者服务是一个简单的过程，它简化为定义一个实现相关 update() 方法的类。（此处同样省略了代码示例，原因同上。）
总结
控制反转通常被认为是一个晦涩难懂的概念，尤其是在 PHP 中，许多开发人员倾向于将其与普通的依赖注入联系起来，但它是一种简单而强大的编程方法，如果正确实现，它是一种创建解耦、正交系统的绝佳方法，其组件可以轻松地隔离测试。如果您在应用程序中使用依赖注入（您确实在使用，对吧？），那么您应该会感到您的程序员本能得到了很好的满足，因为您已经在利用控制反转提供的优势。但是，正如我之前试图演示的那样，除了以正确的方式管理类依赖关系之外，还有很多情况适合这种方法。事件驱动设计当然就是一个很好的例子。
（此处省略了FAQ部分，原因同上。）
以上是PHP主|控制倒置 - 好莱坞原则的详细内容。更多信息请关注PHP中文网其他相关文章！
