当第一次遇到控制反转（IoC）时，它可能非常令人困惑。
这是怎么一回事？它解决了哪个问题？什么时候使用合适，什么时候不合适？
当前回答
但我认为你必须非常小心。如果你过度使用这种模式，你会做出非常复杂的设计，甚至更复杂的代码。
就像这个例子中的TextEditor一样：如果你只有一个拼写检查器，那么可能真的没有必要使用IoC？除非你需要写单元测试之类的。。。
无论如何：要讲道理。设计模式是很好的实践，但不是圣经。不要把它粘在任何地方。
其他回答
编程演讲
简单地说，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原则有助于设计松散耦合的类，使其可测试、可维护和可扩展。
只回答第一部分。这是怎么一回事？
控制反转（IoC）意味着先创建依赖项的实例，然后创建类的后一个实例（可选地通过构造函数注入它们），而不是先创建类的实例，再由类实例创建依赖项实例。因此，控制反转反转程序的控制流程。调用者控制程序的控制流，而不是被调用者控制控制流（同时创建依赖项）。
例如，任务#1是创建对象。没有IOC概念，任务#1应该由程序员完成。但有了IOC概念后，任务#1将由容器完成。
简而言之，控件从编程器转换为容器。因此，它被称为控制反转。
我在这里找到了一个很好的例子。
对我来说，IoC/DI正在向调用对象推出依赖项。超级简单。
非技术性的答案是，在你打开引擎之前，你可以更换汽车的引擎。如果一切正常（界面），你就很好了。
