什么是控制反转？

如果您遵循这两个简单的步骤，您就完成了控制反转：

把该做什么和什么时候该做分开。确保零件何时尽可能少地了解什么零件；反之亦然。

根据您用于实现的技术/语言，这些步骤中的每一个都有几种可能的技术。

--

控制反转（IoC）的反转部分令人困惑；因为反转是相对项。了解IoC的最好方法是忘记这个词！

--

示例

事件处理。事件处理程序（做什么部分）--引发事件（何时做部分）依赖注入。构造依赖项（做什么部分）的代码——在需要时为客户机实例化和注入依赖项，这通常由Dagger等DI工具来处理（什么时候做部分）。接口。组件客户端（何时执行部分）--组件接口实现（执行部分）x装置夹具。Setup和TearDown（要做的部分）--xUnit框架在开始时调用Setup，在结束时调用TearDown（何时做部分）模板方法设计模式。模板方法何时执行部分--基本子类实现何时执行部分COM.DllMain、DllCanUnload等中的DLL容器方法（做什么部分）--COM/OS（什么时候做部分）

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

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

控制反转有三种类型：

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

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

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

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

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

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

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

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

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

控制反转是当程序回调时得到的结果，例如gui程序。

例如，在旧学校菜单中，您可能有：

print "enter your name"
read name
print "enter your address"
read address
etc...
store in database

从而控制用户交互的流程。

在GUI程序或类似程序中，我们会说：

when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase

所以现在控制反转了。。。代替计算机以固定的顺序接受用户输入，用户控制输入数据的顺序以及数据保存在数据库中的时间。

基本上，任何带有事件循环、回调或执行触发器的东西都属于这一类。

所以上面的数字1。什么是控制反转？维护是它为我解决的首要问题。它保证我使用的是接口，这样两个类就不会彼此亲密。

使用温莎城堡这样的容器，它可以更好地解决维护问题。能够在不更改一行代码的情况下，将一个连接到数据库的组件替换为一个使用基于文件的持久性的组件，这是非常棒的（配置更改完成了）。

一旦你进入泛型，它会变得更好。想象一下，拥有一个接收记录并发布消息的消息发布者。它不在乎它发布了什么，但它需要一个映射器将记录中的内容转换为消息。

public class MessagePublisher<RECORD,MESSAGE>
{
    public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
    {
      //setup
    }
}

我写过一次，但现在如果我发布不同类型的消息，我可以向这组代码中注入许多类型。我还可以编写映射器，将相同类型的记录映射到不同的消息。将DI与Generics结合使用使我能够编写很少的代码来完成许多任务。

哦，是的，存在可测试性问题，但它们比IoC/DI的优势更为次要。

我绝对喜欢IoC/DI。

3.当你有一个中等规模的项目时，它会变得更加合适。我会说，当你开始感到疼痛时，它就变得合适了。

IoC是关于颠倒代码和第三方代码（库/框架）之间的关系：

在正常的软件开发中，您编写main（）方法并调用“library”方法。您可以控制：）在IoC中，“框架”控制main（）并调用您的方法。该框架处于受控状态：(

DI（依赖注入）是关于控件在应用程序中如何流动的。传统的桌面应用程序具有从应用程序（main（）方法）到其他库方法调用的控制流，但DI控制流是反向的，框架负责启动应用程序、初始化应用程序并在需要时调用方法。

最终，你总会赢：）