我解释 DI 和 IoC 的方式有什么问题？答案

【问题标题】：What is wrong in my way of explainning DI and IoC?我解释 DI 和 IoC 的方式有什么问题？
【发布时间】：2015-08-10 12:44:24
【问题描述】：

昨天在一次采访中，有人问我春季的 DI 和 IoC 是什么。我的回复是：

当 class(A) 扩展抽象 class(B) 或实现 interface(B) 或在其中创建任何类的class(B) 的对象，然后A 据说是依赖于B。注入这种依赖，即将对象注入 costructor 或在 setter 方法中称为 DI 并且在此过程中对创建对象的控制权转到 XML 等“外部世界” 配置，这种控制反转就是 IoC。 DI 不是必要的 IOC。在没有 IOC 的情况下，我们仍然可以拥有 DI。

面试官不同意我的看法——我哪里错了？

还有一件事-

因为我们在构造函数或设置方法参数中使用了Super class reference variable 或coding through interface。这是任何方式与DI/IOC相关或者这只是为了实现loose coupling？

【问题讨论】：

虽然从设计角度来看，继承关系被认为是一种依赖，在spring的情况下，只有composition 被认为是一个dependency。您注入 dependent bean 及其 properties
你应该看看this问题。我要说的是 inheritance 示例在 Spring DI 和 IOC 的上下文中并不适用。如果您使用has-a 关系来解释您的理解，那会更有意义
Composition 在 A 类中有一个 B 类的实例，例如作为一个字段。
@dubey-theHarcourtians - 我相信你关于依赖的第一句话是误导

标签： spring dependency-injection inversion-of-control

【解决方案1】：

第一条语句***“当一个类（A）扩展抽象类（B）或实现接口（B）”***

这是继承，不能通过Spring作为依赖注入

第二条语句“创建其中任意类的class(B)的对象，则称A依赖于B”

听起来不错

" 注入这种依赖，即在costructor或setter方法中注入对象称为DI"

没有明确的说明来解释依赖注入。这里需要解释一下注入的含义。也就是说，依赖项的管理由 spring 容器处理，它控制它们的生命周期，从而委托/注入到请求它们的类（通过 spring 配置文件）

“他对创建对象的过程控制像 XML 配置一样进入“外部世界””

这里的控制既不传给外界，也不传给xml配置文件，而是传给spring容器。而spring容器使用这个配置文件来完成它的工作。

“这种控制反转是 IoC。DI 不是必须的 IOC。没有 IOC 时我们仍然可以有 DI。”

虽然没有问题，但似乎不完整。这里需要说明IOC。试图通过图片来解释它

【讨论】：

我认为-如果一个类正在扩展其他类，这取决于此，因为 super 中的任何更改都会反映在子级中。II因为你说控制是容器而不是 xml 文件，不是适当的，因为控制不是由单个实体完成，这是一个小组工作，每个 xml 文件、容器等都涉及这就是我使用外部世界（类）术语的原因。你的答案仍然显示出一种很好的表达方式，那就是 ym 而不是贬低它。
完全同意你的观点，继承是依赖，但我的声明是，继承依赖没有在 Spring 中实现。在第二个陈述中，我同意你的观点，它不是由单个实体进行的小组工作，而是该小组包含在 spring 容器中。

【解决方案2】：

IoC (Inversion of Control) ：与传统的控制流相比，反转控制流控制流，即我们不应该创建对象和控制流，而是框架创建对象，将它们连接在一起并管理它们的生命周期，并使用 DI 来管理组件，即创建对象。

有几种基本技术可以实现控制反转。

使用工厂模式
使用服务定位器模式
使用依赖注入(DI)，例如
- 构造函数注入
- 参数注入
- Setter 注入
- 接口注入
使用上下文查找
使用模板方法设计模式
使用策略设计模式

Source

【讨论】：

【解决方案3】：

您的回答是有道理的，我确实有相同的看法，但略有不同。

IoC 概念最初是在过程编程时代听到的。因此，从历史背景来看，IoC 谈到了所有权控制权的倒置——流程，即谁有责任按所需顺序调用函数——无论是函数本身还是您是否应该将其反转为某个外部实体。

然而，一旦 OOP 出现，人们开始在 OOP 上下文中谈论 IoC，其中应用程序除了控制流之外，还关注对象创建和管理对象之间的关系。这样的应用程序想要反转对象创建（而不是控制流）的所有权，并且需要一个容器来负责对象创建、对象生命周期和注入应用程序对象的依赖关系，从而消除应用程序对象从创建其他具体对象。

从这个意义上说，DI 与 IoC 不同，因为它不是关于控制流，而是一种 Io*，即对象创建的所有权反转。

我已经进一步讨论了这个话题here。

【讨论】：