真的不明白为什么会有很多错误的答案，甚至被接受的答案也不太准确，这让人很难理解。真相总是简单明了的。

正如@Schneider在@Mark Harrison的回答中所评论的，请阅读Martin Fowler关于IoC的帖子。

https://martinfowler.com/bliki/InversionOfControl.html

我最喜欢的是：

这种现象就是控制反转（也称为好莱坞原则——“不要打电话给我们，我们会打电话给你”）。

为什么？

IoC的Wiki，我可以引用一段话。

控制反转用于增加程序的模块性并使其可扩展。。。随后在2004年由Robert C.Martin和Martin Fowler进一步推广。

Robert C.Martin：《清洁代码：敏捷软件工艺手册》的作者。

马丁·福勒：《重构：改进现有代码的设计》一书的作者。

但我认为你必须非常小心。如果你过度使用这种模式，你会做出非常复杂的设计，甚至更复杂的代码。

就像这个例子中的TextEditor一样：如果你只有一个拼写检查器，那么可能真的没有必要使用IoC？除非你需要写单元测试之类的。。。

无论如何：要讲道理。设计模式是很好的实践，但不是圣经。不要把它粘在任何地方。

我知道这里已经给出了答案。但我仍然认为，关于控制反转的一些基础知识必须在这里详细讨论，以供未来读者参考。

控制反转（IoC）建立在一个叫做好莱坞原理的非常简单的原理上。上面说，

不要给我们打电话，我们会给你打电话

这意味着不要去好莱坞实现你的梦想，如果你值得，那么好莱坞会找到你，让你的梦想成真。差不多颠倒了，嗯？

现在，当我们讨论IoC的原理时，我们常常忘记好莱坞。对于IoC来说，必须有三个要素，一个好莱坞，一个你和一个完成你梦想的任务。

在我们的编程世界中，Hollywood代表一个通用框架（可能由您或其他人编写），您代表您编写的用户代码，任务代表您希望用代码完成的任务。现在，你永远不会自己触发任务，而不是在IoC！相反，你已经设计好了所有的东西，这样你的框架就会触发你的任务。因此，您已经构建了一个可重用的框架，它可以使某人成为英雄或另一人成为恶棍。但这一框架始终处于主导地位，它知道什么时候该挑选某人，而某人只知道自己想要成为什么样的人。

这里将给出一个真实的例子。假设您想开发一个web应用程序。因此，您可以创建一个框架来处理web应用程序应该处理的所有常见事务，如处理http请求、创建应用程序菜单、服务页面、管理cookie、触发事件等。

然后你在你的框架中留下一些钩子，你可以在那里放置更多的代码来生成自定义菜单、页面、cookie或记录一些用户事件等。在每次浏览器请求时，你的框架都会运行并执行你的自定义代码，如果勾住了，然后将其发送回浏览器。

所以，这个想法非常简单。与其创建一个控制一切的用户应用程序，不如先创建一个可重用的框架来控制一切，然后编写自定义代码并将其连接到框架以及时执行这些代码。

Laravel和EJB就是这样一个框架的例子。

参考：

https://martinfowler.com/bliki/InversionOfControl.html

https://en.wikipedia.org/wiki/Inversion_of_control

例如，任务#1是创建对象。没有IOC概念，任务#1应该由程序员完成。但有了IOC概念后，任务#1将由容器完成。

简而言之，控件从编程器转换为容器。因此，它被称为控制反转。

我在这里找到了一个很好的例子。

我将写下我对这两个术语的简单理解：

For quick understanding just read examples*

依赖注入（DI）：依赖注入通常意味着将方法依赖的对象作为参数传递给方法，而不是让方法创建依赖对象。这在实践中意味着，该方法不直接依赖于特定的实现；任何满足要求的实现都可以作为参数传递。使用此对象可以告诉它们的依赖关系。春天使它成为可能。这导致了松散耦合的应用程序开发。

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

控制反转（IoC）容器：这是框架的共同特征，IOC通过其BeanFactory管理java对象——从实例化到销毁-由IoC容器实例化的Java组件称为bean，IoC容器管理bean的范围、生命周期事件以及为其配置和编码的任何AOP特性。

快速示例：控制反转是指获得自由、更大的灵活性和更少的依赖性。当你使用台式电脑时，你是从属的（或者说，受控的）。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个糟糕的书面软件会让你更加痛苦。如果你用笔记本电脑取代了你的桌面，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是电脑控制它。

通过实现控制反转，软件/对象消费者可以获得更多的软件/对象控制/选项，而不是被控制或拥有更少的选项。

作为设计指南的控制反转具有以下目的：

某个任务的执行与实现是分离的。每个模块都可以专注于它的设计目的。模块不假设其他系统做什么，而是依赖它们的合同。替换模块对其他模块没有任何副作用，我将在这里保持抽象，您可以访问以下链接以详细了解主题。一个很好的例子

详细说明

我已经读了很多关于这一点的答案，但如果有人仍然感到困惑，需要一个额外的“外行术语”来解释IoC，我的看法是：

想象一个父母和孩子彼此交谈。

没有IoC：

*家长：我问你问题时你才能说话，我允许你时你才能行动。

家长：这意味着，如果我不问你，你就不能问我你能不能吃饭、玩、上厕所甚至睡觉。

家长：你想吃吗？

孩子：没有。

家长：好的，我会回来的。等我。

孩子：（想玩，但由于家长没有问题，孩子什么都不会做）。

1小时后。。。

家长：我回来了。你想玩吗？

孩子：是的。

父级：已授予权限。

孩子：（终于可以玩了）。

这个简单的场景解释了控件以父级为中心。孩子的自由受到限制，高度依赖于父母的问题。孩子只有在被要求说话时才能说话，只有在获得许可时才能行动。

使用IoC：

孩子现在有能力提出问题，家长可以回答并获得许可。简单地说就是控制颠倒了！孩子现在可以随时提问，尽管在权限方面仍然依赖于家长，但他不依赖于说话/提问的方式。

从技术上解释，这与console/shell/cmd与GUI交互非常相似。（这是马克·哈里森的答案，排名第二）。在控制台中，您依赖于向您询问/显示的内容，如果不先回答问题，您无法跳转到其他菜单和功能；遵循严格的顺序流程。（编程上这就像一个方法/函数循环）。然而，有了GUI，菜单和功能就被布置好了，用户可以选择所需的任何内容，从而拥有更多的控制权和更少的限制。（以编程方式，菜单在选中并执行操作时具有回调）。