控制反转是当程序回调时得到的结果，例如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

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

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

真的不明白为什么会有很多错误的答案，甚至被接受的答案也不太准确，这让人很难理解。真相总是简单明了的。

正如@Schneider在@Mark Harrison的回答中所评论的，请阅读Martin Fowler关于IoC的帖子。

https://martinfowler.com/bliki/InversionOfControl.html

我最喜欢的是：

这种现象就是控制反转（也称为好莱坞原则——“不要打电话给我们，我们会打电话给你”）。

为什么？

IoC的Wiki，我可以引用一段话。

控制反转用于增加程序的模块性并使其可扩展。。。随后在2004年由Robert C.Martin和Martin Fowler进一步推广。

Robert C.Martin：《清洁代码：敏捷软件工艺手册》的作者。

马丁·福勒：《重构：改进现有代码的设计》一书的作者。

控制反转（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类型的全局使用的实例（服务）（这可能不存储所述实例，而是一次又一次地询问提供者）。

控制权倒置是项目责任转移的一个指标。

当依赖项被授予直接作用于调用者空间的能力时，每次都会发生控制反转。

最小的IoC是通过引用传递变量，让我们先看看非IoC代码：

function isVarHello($var) {
    return ($var === "Hello");
}

// Responsibility is within the caller
$word = "Hello";
if (isVarHello($word)) {
    $word = "World";
}

现在，让我们通过将结果的责任从调用者转移到依赖项来反转控制：

function changeHelloToWorld(&$var) {
    // Responsibility has been shifted to the dependency
    if ($var === "Hello") {
        $var = "World";
    }
}

$word = "Hello";
changeHelloToWorld($word);

下面是另一个使用OOP的示例：

<?php

class Human {
    private $hp = 0.5;

    function consume(Eatable $chunk) {
        // $this->chew($chunk);
        $chunk->unfoldEffectOn($this);
    }

    function incrementHealth() {
        $this->hp++;
    }
    function isHealthy() {}
    function getHungry() {}
    // ...
}

interface Eatable {
    public function unfoldEffectOn($body);
}

class Medicine implements Eatable {
    function unfoldEffectOn($human) {
        // The dependency is now in charge of the human.
        $human->incrementHealth();
        $this->depleted = true;
    }
}

$human = new Human();
$medicine = new Medicine();
if (!$human->isHealthy()) {
    $human->consume($medicine);   
}

var_dump($medicine);
var_dump($human);

*)免责声明：现实世界中的人类使用消息队列。

对我来说，IoC/DI正在向调用对象推出依赖项。超级简单。

非技术性的答案是，在你打开引擎之前，你可以更换汽车的引擎。如果一切正常（界面），你就很好了。

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

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

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

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

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

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