暗藏具体实现
上次（链接：vscode 初探）咱们对 vscode 的根本构造和次要模块的作用进行了剖析，如果有同学看过它的源码，会发现想要定位到某个模块的具体实现是不容易的。这是因为 vscode 采纳了一种低耦合的模块架构，即在具体编写某个类的过程中，你所依赖的类被无意暗藏了。从架构师的角度，心愿每个开发者专一本人负责的模块，不应该关怀和理解其他人写好的模块（升高心智老本），然而如果你的模块对另外一个同学有依赖，应该怎么办呢？答案是通过接口提供，这也是面向对象编程的外围，模块依赖接口，屏蔽具体实现。这样的益处是模块与模块之间低耦合。
这样讲比拟形象，咱们举个例子，你编写的模块 A 依赖小明同学写的一个打印功能模块 B，而架构师说，你不能间接调用它的代码，必须让小明实现接口 P，你再引入接口 P 即可。而后架构师再让代码运行的时候，小明的打印代码会主动被调用。
前面小明负责的那个打印机被淘汰了，让小王负责实现某个新品种的打印机功能模块 C。你想找小王对接，架构师说，不要找他沟通了，小王的打印模块实现咱们之前约定的接口 P 即可，你的代码不必做任何调整，零碎会主动在运行时调用小王写的模块 C。
接口 P 的实现能够是 B，也能够是 C，这种体现也叫多态（面向对象中的子类多态）。在大部分语言，比方 c#、java 等都提供了这样的概念，有的叫接口、有的叫抽象类。这种用于屏蔽具体实现的概念，在前端开发畛域又叫“鸭子类型”，相熟 vscode 的前提是肯定要具备面向对象思维。
如何保护海量模块
在 vscode 源码中，模块的数量是成千上万。在多人合作和重复迭代的过程中，vscode 团队如何无效的治理这些对象？答案是 DI（依赖注入），了解它是深刻 vscode 的外围。Java Spring、Angular 框架有相似的概念，但在大部分前端开发中不常见。所以在正式接触 vscode 本身实现的 DI 之前，咱们循序渐进的介绍下为什么会须要 DI，它解决了什么痛点，做了哪些事件。
咱们举个简略例子，理论状况会更简单复。以下 class 代表一个类, 大部分场景也能叫模块，类初始化后咱们叫的实例、或者对象，前面这些名词会不加区分。案例：class1 依赖 : 2, 3, 4 class2 依赖 : 5, 6, class3 依赖 : 7, 8 class4 依赖 : 5，7 class7 依赖：11，12 calss6 依赖：…
以此类推，在零碎中，模块依赖的层级会十分深。
咱们给下面这个模型进行编码（伪代码）
// class1 依赖 2，3，4
import Class5 from Class5
import Class7 from Class7
import Class2 from Class2
import Class3 from Class3
import Class4 from Class4
class Class1 {constructor() {
// commom start 独特依赖
this.instance5 = new Class5();
this.instance7 = new Class7();
// commom send
this.instance2 = new Class2(this.instance5);
this.instance3 = new Class3(this.instance7);
this.instance4 = new Class4(this.instance5，this.instance7)
}
}
// class2 依赖 5, 6
import Class8 from Class6
class Class2 {constructor(instance5) {
this.instance5 = instance5;
this.instance6 = new Class6();}
}
// class3 依赖 7, 8
import Class8 from Class8
class Class3 {constructor(instance7) {
this.instance7 = instance7;
this.instance8 = new Class8();}
}
// class 4 依赖 5，7
import Class5 from Class5
import Class7 from Class7
class Class4 {constructor() {this.instance7 = new Class5();
this.instance8 = new Class7();}
}
// class 7 依赖 11，12
import Class11 from Class11
import Class12 from Class12
class Class7 {constructor() {this.instance11 = new Class11();
this.instance12 = new Class12();}
}通常简略的场景，咱们会间接在类外部 new 一个类，作为依赖挂载在属性成员下。
class Class7 {constructor() {this.instance11 = new Class11();
// ... 参考下面代码
}
}如上，咱们在 class7 中 new Class11，它们的关系是强依赖，即 class 7 在外部援用 class 11 的源代码，同时管制 class 11 的初始化过程。这种依赖会随着迭代变得不可保护，比方某一天 Class11 实现扭转了，Class11 须要被替换成其余类，咱们依然须要到 class 7 和其余相似的模块中进行批改。
独特依赖
假如如上 instance11 须要同时被其余 classX 所须要呢？咱们能够把创立好的 instance11 别离作为参数传给多个被依赖的 class X。
class Class1 {
/**
共用依赖 5
class 2 -> instance5
class 4 -> instance5
共用依赖 7
class 3 -> instance7
class 4 -> instance7
*/
constructor() {
// 在内部初始化
// commom start 独特依赖
this.instance5 = new Class5();
this.instance7 = new Class7();
// commom send
this.instance2 = new Class2(this.instance5);
this.instance3 = new Class3(this.instance7);
this.instance4 = new Class4(this.instance5，this.instance7)
}
}在下面伪代码中，instance5 和 instance7 别离是被两个类 class2、3 所依赖的实例，于是，咱们找到 class 2 和 class 3 独特向上依赖的类 class1，即在内部提前初始化 instance5，instance7，作为参数传递给 class 2 和 class3 上来。
这样你会发现，随着利用的复杂化，会须要小心翼翼，我创立的某个类所依赖的这些实例，它们是否间接在 class 构造函数中间接 new 进去？如果同时被其余类依赖，那我须要去哪里找到这些类呢，又应该在哪写中央初始化这些实例？
循环依赖
另外在依赖逐步减少的过程，循环依赖的问题非常容易呈现。class 2 依赖 class 7, 而 class 7 依赖 class 11。假如有一个开发在 class 11 中依赖了 class 2，那么就成了依赖循环依赖。循环依赖会如果在构建过程没有检测进去，程序运行的时候，会呈现援用为空的等 bug。
能够设想，在 N * M 依赖简单的利用中，纯靠开发手工保护类之间的关系，老本十分大，在成千上万个模块中，每个人只编写其中一小模块，在不理解全面的状况下，略微不小心改变一个点，十分引发灾难性雪崩，而这样的强依赖关系，前期根本无奈保护。
解除源码依赖
为了让每个类不依赖其余类的源代码，咱们能够把全副实例的初始化放在类的内部进行，就像解决独特依赖那样。比方某个入口函数，主类等。在下面例子中，咱们能够这样调整。
class Class1 {constructor() {
// 在入口函数全副初始化
// 须要按先后顺序申明上、中下层的依赖
this.instance11 = new Class11();
this.instance12 = new Class12();
this.instance5 = new Class5();
// 间接把依赖的示例传入
this.instance7 = new Class7(this.instance11, this.instance12);
this.instance2 = new Class2(this.instance5);
this.instance3 = new Class3(this.instance7);
this.instance4 = new Class4(this.instance5，this.instance7)
}
}
// 其余类代码略...
// 每个类能够不须要源码级别的引入依赖 比方 import 语句
在最外层初始化依赖的益处是，本来须要通过 import(include/useing)等申明，把依赖进行源码级别的引入，当初变成了，把依赖变成运行时的实例作为参数传入。
当初，咱们有了更进一步的维护性、对于每个模块的使用者，再也不必关系依赖模块的源码在哪里。而是承受参数，间接应用即可。
但这种状况还是有一个问题：对于在外层负责初始化模块的同学，他必须要理解整个我的项目全副模块的细节，剖析依赖先后关系，而后在适合的中央创立好它。这是一个不小的体力活，并且容易出错，面对循环依赖等问题也须要认真排查，每次代码变更少不了这位“大神”的参加，发现有不符合要求的模块，让负责人进行批改。假如某天这位“大神”休假了，那我的项目可能就十分蹩脚。
依赖注入
这样一种工作能不能自动化实现呢？
DI（依赖注入）框架就是专门做这样一件事的。也就是说，在大型项目中，咱们须要有这样一种机制：
1、模块与模块之间的无源码依赖（这里的模块次要指类）
2、只依赖接口 / 形象，不依赖具体实现
3、模块的创立，循环援用、谬误等能够主动被捕捉到
最终，咱们能够看到的如上图的成果，本来 Class2 对 Class 5 源码级别的依赖。变成 Class2 依赖 InterfaceClass5，而 Class 5 负责实现 InterfaceClass5 接口即可。这样的一种关系 / 准则，咱们叫做依赖反转（DI 只是一种具体实现），能够看到 Class2 向下间接管制 Class5 的方向，变成了 Class5 实现 InterfaceClass5 接口，接口是两头桥梁，Class2 和 class 5 在方向是相同的。（这样讲不晓得艰深否，能够联合下面的图片箭头方向了解）
上面是最终代码示例：
class Class2 {constructor(@aotuInject priinstance5: InterfaceClass5, @aotuInject instance6: InterfaceClass6) {
this.instance5 = instance5;
this.instance6 = instance6;
}
}Class 2 只须要关怀 InterfaceClass5 裸露了什么接口，而具体的实现却被刻意屏蔽了。这个过程由 DI 框架主动负责。
结
到这里，咱们简略的阐明了通过接口形象、多态等思维在 vscode 设计过程的重要性，它是可维护性的前提。再通过一个例子介绍了依赖注入可能解决什么问题，须要做什么事件。上面一步，我会把 vscode 中对 DI 的实现详情介绍下。提前预报（剧透）下，利用 typescipt 装璜器，及接口名和装璜描述符保持一致的奇妙设计，十分惊艳，源码在几百行左右。
————————
文档信息
公布工夫：2022-05-09
笔名：混沌福王
版权申明：如需转载，请邮件知会 imwangfu@gmail.com，保留此申明
————————