使用IoC，您不会对对象进行更新。您的IoC容器将做到这一点，并管理它们的生命周期。

它解决了必须手动将一种类型对象的每个实例化更改为另一种类型的问题。

如果您的功能将来可能会发生变化，或者根据中使用的环境或配置而有所不同，则使用此选项是合适的。

假设你是一个物体。然后你去餐馆：

没有IoC：你要求“苹果”，当你要求更多时，你总是得到苹果。

与IoC：你可以要求“水果”。每次上桌你都可以得到不同的水果。例如，苹果、橙子或西瓜。

所以，很明显，当你喜欢品种时，IoC是首选。

控制反转是一个通用原则，而依赖注入将这一原则实现为对象图构造的设计模式（即配置控制对象如何相互引用，而不是对象本身控制如何获取对另一个对象的引用）。

将控制反转视为一种设计模式，我们需要看看我们正在反转什么。依赖注入反转了对构建对象图的控制。如果用外行的术语来说，控制反转意味着程序中控制流的改变。例如，在传统的独立应用程序中，我们有一个主要的方法，从那里控制权被传递给其他第三方库（在这种情况下，我们使用了第三方的库的功能），但通过控制反转，控制权从第三方程序库代码转移到我们的代码，因为我们正在使用第三方代码库的服务。但在程序中还有其他方面需要反转，例如调用方法和线程来执行代码。

对于那些对控制反转感兴趣的人来说，已经发表了一篇论文，概述了控制反转作为一种设计模式的更完整的图景（OfficeFloor:使用办公模式来改进软件设计http://doi.acm.org/10.1145/2739011.2739013免费下载http://www.officefloor.net/about.html).

确定的关系如下：

控制反转（用于方法）=依赖（状态）注入+连续注入+线程注入

可用控制反转的上述关系汇总http://dzone.com/articles/inversion-of-coupling-control

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

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

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

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

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

控制反转，（或IoC），是关于获得自由（你结婚了，失去了自由，你被控制了。你离婚了，你刚刚实现了控制反转。这就是我们所说的“脱钩”。好的计算机系统阻碍了一些非常亲密的关系。)更灵活（你办公室的厨房只供应干净的自来水，这是你想喝水时的唯一选择。你的老板通过安装一台新的咖啡机实现了控制反转。现在你可以灵活选择自来水或咖啡。)和更少的依赖性（你的伴侣有工作，你没有工作，你在经济上依赖你的伴侣，所以你受到控制。你找到了工作，你实现了控制反转。良好的计算机系统鼓励依赖。）

当你使用台式电脑时，你已经从（或者说，被控制）了。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个写得不好的软件会让你更加痛苦。如果你把桌面换成笔记本电脑，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是由电脑控制。

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

考虑到上述想法。我们仍然错过了IoC的一个关键部分。在IoC的场景中，软件/对象使用者是一个复杂的框架。这意味着您创建的代码不是自己调用的。现在让我们来解释一下为什么这种方式对web应用程序更有效。

假设您的代码是一组工作人员。他们需要造一辆车。这些工人需要一个地方和工具（软件框架）来制造汽车。一个传统的软件框架就像一个有很多工具的车库。因此，工人们需要自己制定计划，并使用工具来制造汽车。造一辆车不是一件容易的事，工人们很难做好计划并进行适当的合作。一个现代化的软件框架将像一个拥有所有设施和管理人员的现代化汽车工厂。工人不必制定任何计划，管理者（框架的一部分，他们是最聪明的人，制定了最复杂的计划）将帮助协调，以便工人知道何时完成他们的工作（框架调用您的代码）。工人们只需要足够灵活地使用经理给他们的任何工具（通过使用依赖注入）。

尽管工人将项目管理的控制权交给了管理者（框架）。但有一些专业人士帮助是很好的。这就是IoC的真正来源。

具有MVC架构的现代Web应用程序依赖于框架来执行URL路由，并将控制器放置在适当的位置以供框架调用。

依赖注入和控制反转是相关的。依赖注入在微观层面，控制反转在宏观层面。为了完成一顿饭（实现IoC），你必须吃每一口（实现DI）。

由于这个问题已经有很多答案，但没有一个显示反转控制项的分解，我认为有机会给出一个更简洁和有用的答案。

控制反转是一种实现依赖反转原理（DIP）的模式。DIP声明如下：1。高级模块不应依赖于低级模块。两者都应该依赖于抽象（例如接口）。2.摘要不应依赖于细节。细节（具体实现）应该依赖于抽象。

控制反转有三种类型：

界面反转提供程序不应定义接口。相反，使用者应该定义接口，提供者必须实现它。接口反转允许消除每次添加新提供者时修改使用者的必要性。

流量反演更改流量控制。例如，您有一个控制台应用程序，要求输入许多参数，在输入每个参数后，您必须按enter键。您可以在此处应用Flow Inversion，并实现桌面应用程序，用户可以选择输入参数的顺序，用户可以编辑参数，在最后一步，用户只需按Enter键一次。

创建反转它可以通过以下模式实现：工厂模式、服务定位器和依赖注入。创建反转有助于消除类型之间的依赖关系，将依赖关系对象创建过程移到使用这些依赖关系对象的类型之外。为什么依赖关系不好？这里有几个例子：在代码中直接创建一个新对象会使测试更加困难；不重新编译就不可能更改程序集中的引用（违反OCP原则）；你不能轻易地用web UI替换桌面UI。