我解释国际奥委会和国际奥委会的方式有什么不对？

Question

昨天在一次采访中，有人问我，Spring的国际奥委会和国际奥委会是什么。我的回答是：

当a类（a）扩展抽象的类（B）或实现接口（B）或创建其中任何类的类（B）的对象时，则称a依赖于B。注入这种依赖关系，即在costructor或setter方法中注入对象称为DI，在这个过程中，对创建对象的控制权转移到“外部世界”，比如XML配置，这种控制权的反转是IoC。国际奥委会不需要DI。在没有国际奥委会的情况下，我们仍然可以使用DI。

面试官不同意我的观点——我错在哪里？

还有一件事-

因为我们在构造函数或setter方法参数中使用了超类参考变量或通过接口编码。这是否与DI/IOC有关，或者这只是为了实现松耦合？

Answer 1

你的回答让森斯和我有着相同的看法，只是略有不同。

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

然而，一旦OOP出现，人们就开始在OOP环境中谈论IoC，在OOP环境中，除了控制流之外，应用程序还涉及对象创建和管理对象之间的关系。这类应用程序想要反转对象创建（而不是控制流）的所有权，并需要一个负责对象创建、对象生命周期的容器

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

我在这里进一步讨论了这个话题。

Answer 2

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

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

第二条语句“创建其中任何一个类的类（B）的对象，则a称为依赖于B”

听起来不错

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

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

“他对创建对象的过程控制权流向了“外部世界”，比如XML配置”

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

“这种控制反转是IoC。DI不是必要的IoC。在没有IoC的情况下，我们仍然可以使用DI。”

虽然没有问题，但似乎不完整。这里需要解释一下。试图通过图像来解释它

Answer 3

IoC（控制反转）：与传统控制流相比，反转控制流，即我们不应创建对象和控制流，而应创建对象，将它们连接在一起并管理其生命周期，并使用DI管理组件，即创建对象。

实现控制反演有几种基本技术。

• 使用工厂模式
• 使用服务定位器模式
• 例如，使用依赖注入（DI）
  • 构造函数注入
  • 参数注入
  • 塞特注射
  • 界面注入

  来源