我在使用库或框架的上下文中想到了控制反转。

传统的“控制”方式是我们构建一个控制器类（通常是主类，但也可以是任何类型的），导入一个库，然后使用您的控制器类来“控制”软件组件的操作。就像你的第一个C/Python程序（继HelloWorld之后）。

import pandas as pd
df = new DataFrame()
# Now do things with the dataframe.

在这种情况下，我们需要知道Dataframe是什么才能使用它。您需要知道要使用什么方法，它的取值方式等等。如果您通过多态性将它添加到自己的类中，或者只是重新调用它，那么您的类将需要Dataframe库才能正常工作。

“控制反转”意味着过程反转。您可以注册类并将其发送回要控制的引擎，而不是您的类控制库、框架或引擎的元素。换句话说，IoC可能意味着我们正在使用代码来配置框架。您也可以将其视为类似于我们在map或filter中使用函数来处理列表中的数据的方式，只是将其应用于整个应用程序。

如果您是构建引擎的人，那么您可能正在使用依赖注入方法（如上所述）来实现这一点。如果你是一个使用引擎的人（更常见），那么你应该能够只声明类，添加适当的符号，让框架为你完成剩下的工作（例如创建路由、分配servlet、设置事件、输出小部件等）。

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

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

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

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

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

但我认为你必须非常小心。如果你过度使用这种模式，你会做出非常复杂的设计，甚至更复杂的代码。

就像这个例子中的TextEditor一样：如果你只有一个拼写检查器，那么可能真的没有必要使用IoC？除非你需要写单元测试之类的。。。

无论如何：要讲道理。设计模式是很好的实践，但不是圣经。不要把它粘在任何地方。

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

赞成的意见：

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

欺骗：

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

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

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

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

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

确定的关系如下：

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

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

编程演讲

简单地说，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提供两类服务（具有类似的功能），这很糟糕。