我正在阅读Head First Design模式，并坚持好莱坞原则。之前我读过关于控制反转和我理解的内容，这是一个设计原则（有些也称之为模式），通过这个原则，传统的程序流程从“更高级模块调用低级模块”变为“ 下级模块调用高级模块“（通常通过抽象），因此我们可以对特定的低级模块具有非常低的依赖性，并且更改低级模块对我们的更高级别没有任何影响或靠近商业模块。
但是当作者说出关于好莱坞原则的以下内容时，我感到很困惑： -
第296页
根据好莱坞原则，我们允许使用低级组件 将自己挂钩到系统中，但是高级别 组件确定何时需要它们以及如何。在 换句话说，高级组件给出了低级别 组件“不要打电话给我们，我们会打电话给你”。
在最后一行，据说高级组件给出了低级别 组件“不要打电话给我们，我们会叫你”处理。这意味着我们的高级组件实际上是调用低级组件，因此 这似乎打破了控制原理的倒置和依赖倒置原则。
请澄清一下。
答案 0 :(得分：0)
好莱坞原则与控制反转并不矛盾，尽管可以忽略它来编程。
在书中的咖啡示例（我猜一页之后，我有另一版）子类通过好莱坞原则调用两种方法。如果子类只是覆盖了基类中的一些抽象方法，那么它实际上并没有使用控制反转。
然而，由于被调用的子类可以调整基类的成员，因此可以采用这种方式进行控制。在我的书中的Q和A之前的一页中，它解释了一个问题：什么是真正应该用于的钩子。我会尝试解释。
假设你有一个带有未排序列表的基类和一个print（）调用列表。如果你有一个子类，通过一个钩子可以调用来覆盖print（），那么子类可能决定首先对基类的实际列表进行排序，而不是在需要时调用其他函数。通过这种方式，低电平功能可以接管来自高电平功能的控制。
答案 1 :(得分：0)
IoC有时被称为好莱坞原则。它们是相同的...但是，像所有习惯用语一样，它总是受语义限制。从更高级别的抽象中控制低级别依赖关系的原则不是“模式”，而是一个原则。通过将该原则仅与子分类相关联，也没有很好的例证，尽管它最自然地存在。
更常见的是，它通过在低级对象中保留对某些接口或抽象类型的引用并将依赖项注入该类来通过组合/聚合来完成。它对收到的东西没有控制权或责任，只知道如何处理它。
换句话说，它（低级别）必须等待手机，而不是要求下一次放映，试镜？他们在好莱坞所谓的那种。
答案 2 :(得分：0)
在设计软件时，我们实现了API和Framework这两个要素。
API发布一些终结点，以便调用者使用这些终结点来获取一些有用的信息，因此，调用者没有任何动作点，只需终结点和输出即可。
该框架从调用者那里获取策略或业务实施，并在需要时调用它。
在好莱坞原则中，我们可以提供我们的策略或业务实施，表示框架实施，该框架在需要时称为联合战略。
控制和依赖注入的反转是为了删除应用程序的依赖。这使得系统更加解耦和可维护。
如果您回到过去的计算机编程时代，程序流通常会在自己的控件中运行。
如果您仔细分析程序流程，它是顺序的。该程序由自己控制。控制权的反转意味着程序将控制权委托给其他将推动流程的人。
答案 3 :(得分：0)
如果我们专注于依赖倒置原则的不同部分，那么看来的矛盾就会消除：
A。高级模块不应依赖于低级模块。 两者都应依赖抽象。
B.抽象不应依赖细节。 细节应取决于抽象。
这添加了一些上下文，以清除此语句造成的潜在混乱：
高级组件为低级组件提供“不打电话给我们，我们会打电话给您”的待遇。
高级组件根本不直接 处理低级组件。它们处理代表底层组件目的或功能的抽象。
因此，它不会“破坏”依赖倒置原则。相反，只需要与该原理相一致地理解它即可。它们是两个不同的原理，因此我们可以应用一个而又可以打破另一个。但是，如果组件之间以抽象表示的方式相互通信，那么我们可以同时应用两者。
他们本可以在所讨论的句子中添加该说明，但这会使它变得更加单词化和混乱。
FWIW我经常会混淆“高级”和“低级”这两个术语，因为除非讨论依赖倒置原则，否则我们不倾向于使用它们。组件是“高级”还是“低级”，建议取决于抽象。换句话说，取决于抽象。我们可以应用该原理，而无需将组件分为高级别或低级别。