我正在看这个关于依赖注入的课程视频,老师谈到了
di-container
但没有详细解释,现在我读了一些文章,我想确认现在我得到了正确的结果。下面是简单的程序,我的问题是,
下面的程序类是一种最简单的双容器吗?如果不是,简单的双容器会是什么样子
interface Implementable {
void doSmth();
}
class A implements Implementable {
@Override
public void doSmth() {
}
}
class B {
private Implementable i;
public B(Implementable implementable) {
this.i= implementable;
}
public void doSmth(){
i.doSmth();
}
}
这个类是双容器吗?
class Program {
B b = new B(new A());
b.doSmth();
}
根据依赖注入原则、实践和模式,DI容器是:
“一个软件库,提供 DI 功能并允许自动执行对象组合、拦截和生命周期管理中涉及的许多任务。DI 容器也称为控制反转 (IoC) 容器。 ”(§3.2.2)
至少,DI 容器允许自动接线,即:
“能够通过使用编译器和[其运行时环境]提供的类型元数据,从抽象和具体类型之间的映射自动构建对象图。”(第 12.1.2 节)
这通常意味着 DI 容器将分析类型的构造函数并向其中注入依赖项,而无需手动指定每个构造函数参数。
从这个角度来看,您的
Program
类不是 DI 容器,但您的 Program
类充当 Composer,它是组合根的一部分。 组合根是:
“应用程序中模块组合在一起的(最好)唯一位置。”(§4.1)
Composer 是 Composition Root 的一部分,负责实际构建对象图。
“它是Composition Root的重要组成部分。Composer通常是一个DI Container,但它也可以是任何手动构造对象图的方法”(§8)
在您的特定组合根中,您正在练习纯 DI,而不是使用 DI 容器,即:
“在没有 DI 容器的情况下应用 DI 的做法。”(§1.1.1)
换句话说,纯 DI 是使用语言的
new
关键字手动构建对象图的做法,而不是使用 DI 容器,正如您的 Program
类所演示的那样。
简单的双容器[看起来]是什么样子
DI 容器实现通常相当复杂,并且有多种构建它们的方法。然而,它们的本质在于抽象和具体类型之间的映射。因此,大多数 DI 容器在内部使用字典或哈希映射。 这个 Stack Overflow 答案 只需几行代码即可实现基于字典的简单实现(使用 C#)。