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

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

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

我最喜欢的是：

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

为什么？

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

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

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

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

控制反转是用于解耦系统中的组件和层的模式。该模式是通过在构建组件时将依赖项注入组件来实现的。这些依赖性通常作为接口提供，用于进一步去耦和支持可测试性。IoC/DI容器（如Castle Windsor、Unity）是可用于提供IoC的工具（库）。这些工具提供了超越简单依赖管理的扩展功能，包括生存期、AOP/Interception、策略等。a.减轻组件对管理其依赖性的责任。b.提供在不同环境中交换依赖实现的能力。c.允许通过模仿依赖关系来测试组件。d.提供在整个应用程序中共享资源的机制。a.进行测试驱动开发时至关重要。如果没有IoC，很难测试，因为被测组件与系统的其他部分高度耦合。b.开发模块化系统时至关重要。模块化系统是一种无需重新编译即可更换组件的系统。c.如果有许多跨领域的问题需要解决，尤其是在企业应用程序中，则至关重要。

控制反转是关于分离关注点。

没有IoC：你有一台笔记本电脑，你不小心弄坏了屏幕。糟糕的是，你发现市场上没有同一型号的笔记本电脑屏幕。所以你被卡住了。

IoC：你有一台台式电脑，你不小心把屏幕弄坏了。你发现你可以从市场上买到几乎所有的桌面显示器，而且它与你的桌面很好地配合。

在这种情况下，您的桌面成功地实现了IoC。它接受各种类型的显示器，而笔记本电脑不接受，它需要一个特定的屏幕来固定。

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

编程演讲

简单地说，IoC：它是使用接口作为特定对象（例如字段或参数）的一种方式，作为某些类可以使用的通配符。它允许代码的可重用性。

例如，假设我们有两个类：狗和猫。两者具有相同的品质/状态：年龄、体型、体重。因此，我可以创建一个名为AnimalService的服务类，而不是创建一个称为DogService和CatService的服务，它只允许在Dog和Cat使用IAnimal接口时使用它们。

然而，从务实的角度来看，它有一些倒退。

a） 大多数开发人员不知道如何使用它。例如，我可以创建一个名为Customer的类，我可以（使用IDE的工具）自动创建一个称为ICustomer的接口。因此，无论接口是否会被重用，找到一个充满类和接口的文件夹并不罕见。它叫做BLOATED。有些人可能会认为“也许在未来我们可以使用它”-|

b） 它有一些限制。例如，让我们讨论一下Dog和Cat的情况，我想添加一个仅针对狗的新服务（功能）。比方说，我想计算训练一只狗所需的天数（trainDays（）），因为猫没用，猫不能训练（我开玩笑）。

b.1）如果我将trainDays（）添加到服务AnimalService中，那么它也适用于猫，并且根本无效。

b.2）我可以在trainDays（）中添加一个条件，它评估使用的类。但这将彻底打破IoC。

b.3）我可以为新功能创建一个名为DogService的新服务类。但是，这将增加代码的可维护性，因为我们将为Dog提供两类服务（具有类似的功能），这很糟糕。

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

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

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

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

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