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

什么是控制反转？

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

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

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

--

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

--

示例

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

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

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

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

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

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

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

我绝对喜欢IoC/DI。

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

控制反转意味着您控制组件（类）的行为。为什么称之为“反转”，因为在这种模式之前，类是硬连线的，并且确定了它们将要做什么。

导入具有TextEditor和SpellChecker类的库。现在，这个拼写检查器自然只检查英语的拼写。假设您希望TextEditor处理德语并能够进行拼写检查，那么您可以控制它。

在IoC的情况下，这种控制是反向的，即它是如何给你的？库将实现如下内容：

它将有一个TextEditor类，然后会有一个ISpellChecker（它是一个接口，而不是一个具体的SpellChecker类），当您在IoC容器中配置东西时，例如Spring，您可以提供自己的“ISpellChecker”实现，它将检查德语的拼写。因此，拼写检查将如何工作的控制权是从该库中获取并交给您的。这是IoC。

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

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

控制反转有三种类型：

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

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

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

控制反转（IoC）模式是关于提供任何类型的回调，它“实现”和/或控制反应，而不是直接执行自己（换句话说，反转和/或将控制重定向到外部处理器/控制器）。依赖注入（DI）模式是IoC模式的一个更具体的版本，它完全是从代码中删除依赖项。

每个DI实现都可以被视为IoC，但不应该称之为IoC。因为实现依赖注入比回调更困难（不要使用通用术语“IoC”来降低产品的价值）。

例如DI，假设您的应用程序有一个文本编辑器组件，并且您希望提供拼写检查。你的标准代码应该是这样的：

public class TextEditor {

    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

我们在这里所做的工作在TextEditor和SpellChecker之间创建了依赖关系。在IoC场景中，我们会这样做：

public class TextEditor {

    private IocSpellChecker checker;

    public TextEditor(IocSpellChecker checker) {
        this.checker = checker;
    }
}

在第一个代码示例中，我们正在实例化SpellChecker（this.checker=new SpellCheckr（）；），这意味着TextEditor类直接依赖于SpellChecker类。

在第二个代码示例中，我们通过在TextEditor的构造函数签名中使用SpellChecker依赖类（而不是在类中初始化依赖项）来创建抽象。这允许我们调用依赖项，然后将其传递给TextEditor类，如下所示：

SpellChecker sc = new SpellChecker(); // dependency
TextEditor textEditor = new TextEditor(sc);

现在，创建TextEditor类的客户端可以控制使用哪个SpellChecker实现，因为我们正在将依赖项注入TextEditor签名中。

注意，就像IoC是许多其他模式的基础一样，上面的示例只是依赖注入类型中的一种，例如：

构造函数注入。IocSpellChecker的实例将自动传递给构造函数，或手动传递给构造函数。沉淀剂注入。IocSpellChecker的实例将通过setter方法或公共属性传递。服务查找和/或服务定位器其中TextEditor将向已知的提供者请求IocSpellChecker类型的全局使用的实例（服务）（这可能不存储所述实例，而是一次又一次地询问提供者）。