控制反转是关于分离关注点。

没有IoC：你有一台笔记本电脑，你不小心弄坏了屏幕。糟糕的是，你发现市场上没有同一型号的笔记本电脑屏幕。所以你被卡住了。

IoC：你有一台台式电脑，你不小心把屏幕弄坏了。你发现你可以从市场上买到几乎所有的桌面显示器，而且它与你的桌面很好地配合。

在这种情况下，您的桌面成功地实现了IoC。它接受各种类型的显示器，而笔记本电脑不接受，它需要一个特定的屏幕来固定。

这是怎么一回事？反转（耦合）控制，更改方法签名的耦合方向。对于反向控制，方法签名的定义由方法实现（而不是方法的调用方）决定。此处完整解释

它解决了哪个问题？方法上的自顶向下耦合。这随后消除了重构的需要。

什么时候使用合适，什么时候不合适？对于定义良好的小型应用程序，如果没有太大的变化，可能会产生开销。然而，对于将要发展的定义较少的应用程序，它减少了方法签名的固有耦合。这使开发人员可以更自由地开发应用程序，避免了对代码进行昂贵的重构。基本上，允许应用程序在很少返工的情况下发展。

为了理解这个概念，控制反转（IoC）或依赖反转原理（DIP）涉及两个活动：抽象和反转。依赖注入（DI）只是为数不多的反转方法之一。

要了解更多信息，您可以在此处阅读我的博客

这是怎么一回事？

这是一种让实际行为来自边界之外的实践（面向对象编程中的类）。边界实体只知道它的抽象（例如面向对象编程中的接口、抽象类、委托）。

它解决了什么问题？

在编程方面，IoC试图通过使单片代码模块化、解耦其各个部分并使其可单元测试来解决单片代码。

什么时候合适，什么时候不合适？

这在大多数情况下都是合适的，除非您有只需要单片代码的情况（例如非常简单的程序）

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

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

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

我同意NilObject，但我想补充一点：

如果你发现自己复制了一个完整的方法，只修改了一小段代码，你可以考虑用控制反转来处理它

如果你发现自己到处复制和粘贴代码，你几乎总是在做错事。编码为“一次且仅一次”的设计原则。

编程演讲

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