在使用“控制反转”之前，你应该充分了解它的优点和缺点，如果你这样做，你应该知道为什么要使用它。

赞成的意见：

您的代码被解耦，因此您可以轻松地将接口的实现与其他实现交换它是针对接口而非实现进行编码的强大动力为代码编写单元测试是非常容易的，因为它只依赖于它在构造函数/setter中接受的对象，并且可以很容易地用正确的对象单独初始化它们。

欺骗：

IoC不仅会反转程序中的控制流，还会使其变得相当模糊。这意味着你不能再只读取代码并从一个地方跳到另一个地方，因为代码中通常存在的连接不再存在。相反，它在XML配置文件或注释中以及IoC容器的代码中解释这些元数据。出现了一类新的错误，即您的XML配置或注释错误，您可以花费大量时间来找出IoC容器在特定条件下向其中一个对象注入空引用的原因。

就我个人而言，我看到了IoC的优点，我非常喜欢它们，但我倾向于尽可能避免使用IoC，因为它将您的软件变成一个类的集合，这些类不再构成“真正的”程序，而只是需要通过XML配置或注释元数据组合在一起的东西，如果没有IoC，它就会崩溃。

维基百科文章。对我来说，控制反转就是将您按顺序编写的代码转换为委托结构。您的程序不是显式地控制一切，而是设置一个类或库，其中包含发生某些事情时要调用的某些函数。它解决了代码重复。例如，在过去，您可以手动编写自己的事件循环，在系统库中轮询新事件。现在，大多数现代API只需告诉系统库您感兴趣的事件，它会让您知道它们何时发生。控制反转是减少代码重复的一种实用方法，如果您发现自己复制了整个方法，只更改了一小段代码，可以考虑使用控制反转来解决它。在许多语言中，通过委托、接口甚至原始函数指针的概念，控制反转变得容易。它并不适合在所有情况下使用，因为这样编写时，程序的流程可能更难遵循。在编写可重用的库时，这是一种设计方法的有用方法，但除非它真的解决了代码重复问题，否则应该在自己程序的核心中谨慎使用。

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

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

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

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

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

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

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

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

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

这里可以找到非常简单的书面解释

http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html

上面写着-

“任何非平凡的应用程序都由两个或多个类组成相互协作以执行一些业务逻辑。传统上，每个对象都负责获得自己的对其协作对象（其依赖项）的引用。应用DI时，对象在创建时被赋予其依赖性某个外部实体在系统换句话说，依赖项被注入到对象中。"

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

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