我解释DI和IoC的方式有什么问题？
昨天在采访中，我被问到春季的DI和IoC是什么。 我的回答是：
当一个class(A)扩展抽象class(B)或实现interface(B)或创建任何类的class(B)的对象时，据说A被依赖于B 注入这种依赖性，即将对象注入到构造函数或setter方法中称为DI，在此过程中，对创建对象的控制像XML配置一样进入“外部世界”，此控制反转为IoC。 DI不是必需的IOC。 没有国际奥委会时，我们仍然可以有直接投资。
面试官不同意我 - 我错在哪里？
还有一件事-
正如我们在构造函数或setter方法参数中使用Super class reference variable或coding through interface进行coding through interface这是与DI / IOC有关的任何方式，还是仅用于实现loose coupling ？
第一条语句***“当类（A）扩展抽象类（B）或实现接口（B）时”***
这是继承，它不能通过Spring注入为依赖
第二个陈述“创建一个任何类的类（B）的对象，然后A据说是依赖于B”
听起来不错
“注入这种依赖性，即注入对象在构造函数或setter方法中称为DI”
不是一个明确的声明来解释依赖注入。 这里需要解释注射的含义。 也就是说，依赖关系的管理由spring容器来处理，谁来控制它们的生命周期，从而委托/注入需要它们的类（通过spring配置文件）
“他对创建对象的过程控制转到”外部世界“，如XML配置”
这里的控制既不会去到外部世界，也不会去到xml配置文件，而是去到spring容器。 而spring容器使用这个配置文件来完成它的工作。
“这种控制反转是IoC，DI不是必需的IOC，当没有IOC时，我们仍然可以有DI。”
虽然没有问题，但似乎不完整。 国际奥委会需要解释。 试图通过图像来解释它
IOC（ 我 n版本华氏度 呼叫控制）是一个抽象的概念。 这意味着对象不会直接创建依赖对象，而是从对象范围之外获取。
有几种实现控制反转的基本技术。
资源
链接地址: http://www.djcxy.com/p/82193.html