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

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

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

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

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

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

控制反转有三种类型：

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

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

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

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

控制反转（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

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

假设我们在酒店开会。

我们邀请了很多人，所以我们漏掉了很多壶水和很多塑料杯。

当有人想喝水时，他/她将杯子装满，喝水，然后将杯子扔在地板上。

大约一个小时后，我们的地板上覆盖着塑料杯和水。

让我们在反转控件后尝试：

想象一下，在同一地点举行同一次会议，但我们现在有一个服务员只带一个玻璃杯，而不是塑料杯（Singleton）

当有人想喝酒时，服务员会给他们一杯。他们把它喝了，然后还给服务员。

抛开卫生问题不谈，使用服务员（过程控制）更有效、更经济。

这正是Spring（另一个IoC容器，例如：Guice）所做的。Spring IoC没有让应用程序使用新的关键字（例如，拿一个塑料杯子）创建所需的东西，而是为应用程序提供所需对象（一杯水）的同一杯子/实例（singleton）。

把自己想象成这样一个会议的组织者：

示例：-

public class MeetingMember {

    private GlassOfWater glassOfWater;

    ...

    public void setGlassOfWater(GlassOfWater glassOfWater){
        this.glassOfWater = glassOfWater;
    }
    //your glassOfWater object initialized and ready to use...
    //spring IoC  called setGlassOfWater method itself in order to
    //offer to meetingMember glassOfWater instance

}

有用的链接：-

http://adfjsf.blogspot.in/2008/05/inversion-of-control.htmlhttp://martinfowler.com/articles/injection.htmlhttp://www.shawn-barrett.com/blog/post/Tip-of-the-day-e28093-Inversion-Of-Control.aspx

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

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

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