当第一次遇到控制反转（IoC）时，它可能非常令人困惑。
这是怎么一回事？它解决了哪个问题？什么时候使用合适，什么时候不合适？
当前回答
我喜欢这样的解释：http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/
它开始很简单，还显示了代码示例。
消费者X需要被消费的类Y来完成某件事。这一切都很好，很自然，但X真的需要知道它使用Y吗？
如果X知道它使用的东西具有Y的行为、方法、财产等，而不知道谁真正实现了这些行为，这还不够吗？
通过提取X在Y中使用的行为的抽象定义（如下面的I所示），并让消费者X使用该行为的实例而不是Y，它可以继续做它所做的事情，而不必知道Y的细节。
在上图中，Y实现了I，X使用了I的一个实例。虽然很可能X仍然使用Y，但有趣的是X并不知道这一点。它只知道它使用了实现I的东西。
阅读文章了解更多信息和好处描述，如：
X不再依赖于Y更灵活，可以在运行时决定实现隔离代码单元，更容易测试
...
其他回答
IoC是关于颠倒代码和第三方代码（库/框架）之间的关系：
在正常的软件开发中，您编写main（）方法并调用“library”方法。您可以控制：）在IoC中，“框架”控制main（）并调用您的方法。该框架处于受控状态：(
DI（依赖注入）是关于控件在应用程序中如何流动的。传统的桌面应用程序具有从应用程序（main（）方法）到其他库方法调用的控制流，但DI控制流是反向的，框架负责启动应用程序、初始化应用程序并在需要时调用方法。
最终，你总会赢：）
控制反转是将控制权从库转移到客户端。当我们讨论将函数值（lambda表达式）注入（传递）到控制（改变）库函数行为的高阶函数（库函数）中的客户端时，它更有意义。
因此，这个模式的一个简单实现（具有巨大的含义）是一个更高阶的库函数（它接受另一个函数作为参数）。库函数通过赋予客户端提供“控制”函数作为参数的能力来传递对其行为的控制。
例如，“map”、“flatMap”等库函数是IoC实现。
当然，例如，有限的IoC版本是布尔函数参数。客户端可以通过切换布尔参数来控制库函数。
将库依赖项（承载行为）注入到库中的客户端或框架也可以被视为IoC
这里可以找到非常简单的书面解释
http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html
上面写着-
“任何非平凡的应用程序都由两个或多个类组成相互协作以执行一些业务逻辑。传统上，每个对象都负责获得自己的对其协作对象（其依赖项）的引用。应用DI时，对象在创建时被赋予其依赖性某个外部实体在系统换句话说，依赖项被注入到对象中。"
假设你是一个物体。然后你去餐馆：
没有IoC：你要求“苹果”，当你要求更多时，你总是得到苹果。
与IoC：你可以要求“水果”。每次上桌你都可以得到不同的水果。例如，苹果、橙子或西瓜。
所以，很明显，当你喜欢品种时，IoC是首选。
IoC原则有助于设计松散耦合的类，使其可测试、可维护和可扩展。
