在类中创建对象称为紧密耦合，Spring通过遵循设计模式（DI/IOC）来消除这种依赖性。在其中类的对象是传入构造函数而不是在类中创建的。此外，我们在构造函数中提供了超类引用变量，以定义更一般的结构。

控制反转是将控制权从库转移到客户端。当我们讨论将函数值（lambda表达式）注入（传递）到控制（改变）库函数行为的高阶函数（库函数）中的客户端时，它更有意义。

因此，这个模式的一个简单实现（具有巨大的含义）是一个更高阶的库函数（它接受另一个函数作为参数）。库函数通过赋予客户端提供“控制”函数作为参数的能力来传递对其行为的控制。

例如，“map”、“flatMap”等库函数是IoC实现。

当然，例如，有限的IoC版本是布尔函数参数。客户端可以通过切换布尔参数来控制库函数。

将库依赖项（承载行为）注入到库中的客户端或框架也可以被视为IoC

当你去杂货店，你妻子给你一份要买的产品清单时，就是控制权倒置。

在编程方面，她将回调函数getProductList（）传递给正在执行的函数-doShopping（）。

它允许函数的用户定义函数的某些部分，使其更加灵活。

只回答第一部分。这是怎么一回事？

控制反转（IoC）意味着先创建依赖项的实例，然后创建类的后一个实例（可选地通过构造函数注入它们），而不是先创建类的实例，再由类实例创建依赖项实例。因此，控制反转反转程序的控制流程。调用者控制程序的控制流，而不是被调用者控制控制流（同时创建依赖项）。

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

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

没有IoC：

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

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

家长：你想吃吗？

孩子：没有。

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

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

1小时后。。。

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

孩子：是的。

父级：已授予权限。

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

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

使用IoC：

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

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

IoC原则有助于设计松散耦合的类，使其可测试、可维护和可扩展。