为了理解IoC，我们应该讨论依赖反转。

依赖反转：依赖于抽象，而不是具体。

控制反转：主与抽象，以及主如何成为系统的粘合剂。

我写了一些很好的例子，你可以在这里查看：

https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/

https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/

https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/

控制反转是用于解耦系统中的组件和层的模式。该模式是通过在构建组件时将依赖项注入组件来实现的。这些依赖性通常作为接口提供，用于进一步去耦和支持可测试性。IoC/DI容器（如Castle Windsor、Unity）是可用于提供IoC的工具（库）。这些工具提供了超越简单依赖管理的扩展功能，包括生存期、AOP/Interception、策略等。a.减轻组件对管理其依赖性的责任。b.提供在不同环境中交换依赖实现的能力。c.允许通过模仿依赖关系来测试组件。d.提供在整个应用程序中共享资源的机制。a.进行测试驱动开发时至关重要。如果没有IoC，很难测试，因为被测组件与系统的其他部分高度耦合。b.开发模块化系统时至关重要。模块化系统是一种无需重新编译即可更换组件的系统。c.如果有许多跨领域的问题需要解决，尤其是在企业应用程序中，则至关重要。

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

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特性。

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

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

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

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

详细说明

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

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

IoC原则有助于设计松散耦合的类，使其可测试、可维护和可扩展。

所以上面的数字1。什么是控制反转？维护是它为我解决的首要问题。它保证我使用的是接口，这样两个类就不会彼此亲密。

使用温莎城堡这样的容器，它可以更好地解决维护问题。能够在不更改一行代码的情况下，将一个连接到数据库的组件替换为一个使用基于文件的持久性的组件，这是非常棒的（配置更改完成了）。

一旦你进入泛型，它会变得更好。想象一下，拥有一个接收记录并发布消息的消息发布者。它不在乎它发布了什么，但它需要一个映射器将记录中的内容转换为消息。

public class MessagePublisher<RECORD,MESSAGE>
{
    public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
    {
      //setup
    }
}

我写过一次，但现在如果我发布不同类型的消息，我可以向这组代码中注入许多类型。我还可以编写映射器，将相同类型的记录映射到不同的消息。将DI与Generics结合使用使我能够编写很少的代码来完成许多任务。

哦，是的，存在可测试性问题，但它们比IoC/DI的优势更为次要。

我绝对喜欢IoC/DI。

3.当你有一个中等规模的项目时，它会变得更加合适。我会说，当你开始感到疼痛时，它就变得合适了。