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

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

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

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

我喜欢这样的解释：http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

它开始很简单，还显示了代码示例。

消费者X需要被消费的类Y来完成某件事。这一切都很好，很自然，但X真的需要知道它使用Y吗？

如果X知道它使用的东西具有Y的行为、方法、财产等，而不知道谁真正实现了这些行为，这还不够吗？

通过提取X在Y中使用的行为的抽象定义（如下面的I所示），并让消费者X使用该行为的实例而不是Y，它可以继续做它所做的事情，而不必知道Y的细节。

在上图中，Y实现了I，X使用了I的一个实例。虽然很可能X仍然使用Y，但有趣的是X并不知道这一点。它只知道它使用了实现I的东西。

阅读文章了解更多信息和好处描述，如：

X不再依赖于Y更灵活，可以在运行时决定实现隔离代码单元，更容易测试

...

当你去杂货店，你妻子给你一份要买的产品清单时，就是控制权倒置。

在编程方面，她将回调函数getProductList（）传递给正在执行的函数-doShopping（）。

它允许函数的用户定义函数的某些部分，使其更加灵活。

编程演讲

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

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

我将写下我对这两个术语的简单理解：

For quick understanding just read examples*

依赖注入（DI）：依赖注入通常意味着将方法依赖的对象作为参数传递给方法，而不是让方法创建依赖对象。这在实践中意味着，该方法不直接依赖于特定的实现；任何满足要求的实现都可以作为参数传递。使用此对象可以告诉它们的依赖关系。春天使它成为可能。这导致了松散耦合的应用程序开发。

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

控制反转（IoC）容器：这是框架的共同特征，IOC通过其BeanFactory管理java对象——从实例化到销毁-由IoC容器实例化的Java组件称为bean，IoC容器管理bean的范围、生命周期事件以及为其配置和编码的任何AOP特性。

快速示例：控制反转是指获得自由、更大的灵活性和更少的依赖性。当你使用台式电脑时，你是从属的（或者说，受控的）。你必须坐在屏幕前看着屏幕。用键盘打字，用鼠标导航。一个糟糕的书面软件会让你更加痛苦。如果你用笔记本电脑取代了你的桌面，那么你的控制就有点颠倒了。你可以轻松地拿着它四处走动。所以现在你可以用电脑控制你的位置，而不是电脑控制它。

通过实现控制反转，软件/对象消费者可以获得更多的软件/对象控制/选项，而不是被控制或拥有更少的选项。

作为设计指南的控制反转具有以下目的：

某个任务的执行与实现是分离的。每个模块都可以专注于它的设计目的。模块不假设其他系统做什么，而是依赖它们的合同。替换模块对其他模块没有任何副作用，我将在这里保持抽象，您可以访问以下链接以详细了解主题。一个很好的例子

详细说明