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

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

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

“IoC”这个首字母缩略词和它所代表的名字似乎最让人困惑的是，这个名字太迷人了——几乎是一个喧嚣的名字。

我们真的需要一个名字来描述过程式编程和事件驱动编程之间的区别吗？好吧，如果我们需要的话，但我们是否需要选择一个全新的“比生活更大”的名字，它让人困惑而不是解决问题？

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

在类中创建对象称为紧密耦合，Spring通过遵循设计模式（DI/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更灵活，可以在运行时决定实现隔离代码单元，更容易测试

...

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

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

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