共计 5057 个字符,预计需要花费 13 分钟才能阅读完成。
精读文章:Dependency Injection in JS/TS – Part 1
概述
依赖注入是将函数外部实现形象为参数,使咱们更不便管制这些它们。
原文依照“如何解决无奈做单测的问题、对立依赖注入的入口、如何主动保障依赖程序正确、循环依赖怎么解决、自上而下 vs 自下而上编程思维”的思路,将依赖注入从想法终点,到延长进去的个性连贯的串了起来。
如何解决无奈做单测的问题
如果一个函数内容实现是随机函数,如何做测试?
export const randomNumber = (max: number): number => {return Math.floor(Math.random() * (max + 1));
};
因为后果不受管制,显然无奈做单测,那将 Math.random
函数形象到参数里问题不就解决了!
export type RandomGenerator = () => number;
export const randomNumber = (
randomGenerator: RandomGenerator,
max: number
): number => {return Math.floor(randomGenerator() * (max + 1));
};
但带来了一个新问题:这样毁坏了 randomNumber
函数自身接口,而且参数变得复杂,不那么易用了。
工厂函数 + 实例模式
为了不便业务代码调用,同时导出工厂函数和不便业务用的实例不就行了!
export type RandomGenerator = () => number;
export const randomNumberImplementation =
({randomGenerator}: Deps) =>
(max: number): number => {return Math.floor(randomGenerator() * (max + 1));
};
export const randomNumber = (max: number) =>
randomNumberImplementation(Math.random, max);
这样乍一看是不错,单测代码援用 randomNumberImplementation
函数并将 randomGenerator
mock 为固定返回值的函数;业务代码援用 randomNumber
,因为内置了 Math.random
实现,用起来也是比拟天然的。
只有每个文件都遵循这种双导出模式,且业务实现除了传递参数外不要有额定的逻辑,这种代码就能同时解决单测与业务问题。
但带来了一个新问题:代码中同时存在工厂函数与实例,即同时构建与应用,这样职责不清晰,而且因为每个文件都要提前援用依赖,依赖间容易造成循环援用,即使上从具体函数层面看,并没有产生函数间的循环援用。
对立依赖注入的入口
用一个对立入口收集依赖就能解决该问题:
import {secureRandomNumber} from "secureRandomNumber";
import {makeFastRandomNumber} from "./fastRandomNumber";
import {makeRandomNumberList} from "./randomNumberList";
const randomGenerator = Math.random;
const fastRandomNumber = makeFastRandomNumber(randomGenerator);
const randomNumber =
process.env.NODE_ENV === "production" ? secureRandomNumber : fastRandomNumber;
const randomNumberList = makeRandomNumberList(randomNumber);
export const container = {
randomNumber,
randomNumberList,
};
export type Container = typeof container;
下面的例子中,一个入口文件同时援用了所有构造函数文件,所以这些构造函数文件之间就不须要相互依赖了,这解决了循环援用的大问题。
而后咱们顺次实例化这些构造函数,传入它们须要的依赖,再用 container
对立导出即可应用,对使用者来说无需关怀如何构建,开箱即用。
但带来了一个新问题:对立注入的入口代码要随着业务文件的变动而变动,同时,如果构造函数之间存在简单的依赖链条,手动保护起程序将是一件越来越简单的事件:比方 A 依赖 B,B 依赖 C,那么想要初始化 C 的构造函数,就要先初始化 A 再初始化 B,最初初始化 C。
如何主动保障依赖程序正确
那有没有方法固定依赖注入的模板逻辑,让其被调用时主动依据依赖关系来初始化呢?答案是有的,而且十分的丑陋:
// container.ts
import {makeFastRandomNumber} from "./fastRandomNumber";
import {makeRandomNumberList} from "./randomNumberList";
import {secureRandomNumber} from "secureRandomNumber";
const dependenciesFactories = {
randomNumber:
process.env.NODE_ENV !== "production"
? makeFastRandomNumber
: () => secureRandomNumber,
randomNumberList: makeRandomNumberList,
randomGenerator: () => Math.random,};
type DependenciesFactories = typeof dependenciesFactories;
export type Container = {[Key in DependenciesFactories]: ReturnValue<DependenciesFactories[Key]>;
};
export const container = {} as Container;
Object.entries(dependenciesFactories).forEach(([dependencyName, factory]) => {
return Object.defineProperty(container, dependencyName, {get: () => factory(container),
});
});
最外围的代码在 Object.defineProperty(container)
这部分,所有从 container[name]
拜访的函数,都会在调用时才被初始化,它们会经验这样的解决链条:
- 初始化
container
为空,不提供任何函数,也没有执行任何factory
。 - 当业务代码调用
container.randomNumber
时,触发get()
,此时会执行randomNumber
的factory
并将container
传入。 - 如果
randomNumber
的factory
没有用到任何依赖,那么container
的子 key 并不会被拜访,randomNumber
函数就胜利创立了,流程完结。 - 关键步骤来了,如果
randomNumber
的factory
用到了任何依赖,假如依赖是它本人,那么会陷入死循环,这是代码逻辑谬误,报错是应该的;如果依赖是他人, 假如调用了container.abc
,那么会触发abc
所在的get()
,反复第 2 步,直到abc
的factory
被胜利执行,这样就胜利拿到了依赖
很神奇,固定的代码逻辑居然会依据拜访链路主动嗅探依赖树,并用正确的程序,从没有依赖的那个模块开始执行 factory
,一层层往上,直到顶部包的依赖全副构建实现。其中每一条子模块的构建链路和主模块都是分型的,十分柔美。
循环依赖怎么解决
这倒不是说如何解决函数循环依赖问题,因为:
- 如果函数 a 依赖了函数 b,而函数 b 又依赖了函数 a,这个相当于 a 依赖了本身,神仙都救不了,如果循环依赖能解决,就和申明创造了永动机一样夸大,所以该场景不必思考解决。
- 依赖注入让模块之间不援用,所以不存在函数间循环依赖问题。
为什么说 a 依赖了本身连神仙都救不了呢?
- a 的实现依赖 a,要晓得 a 的逻辑,得先理解依赖项 a 的逻辑。
- 依赖项 a 的逻辑无从寻找,因为咱们正在实现 a,这样递归上来会死循环。
那依赖注入还须要解决循环依赖问题吗?须要,比方上面代码:
const aFactory =
({a}: Deps) =>
() => {
return {
value: 123,
onClick: () => {console.log(a.value);
},
};
};
这是循环依赖最极限的场景,本人依赖本人。但从逻辑上来看,并没有死循环,如果 onClick
触发在 a
实例化之后,那么它打印 123
是合乎情理的。
但逻辑容不得含糊,如果不通过非凡解决,a.value
还真就解析不进去。
这个问题的解法能够参考 spring 三级缓存思路,放到精读局部聊。
自上而下 vs 自下而上编程思维
原文做了一下总结和升华,相当有思考价值:依赖注入的思维习惯是自上而下的编程思维,即先思考包之间的逻辑关系,而不须要真的先去实现它。
相比之下,自下而上的编程思维须要先实现最初一个无任何依赖的模块,再依照程序实现其余模块,但这种实现程序不肯定合乎业务形象的程序,也限度了实现过程。
精读
咱们探讨对象 A
与对象 B
互相援用时,spring 框架如何用三级缓存解决该问题。
无论用 spring 还是其余框架实现了依赖注入,当代码遇到这样的模式时,就碰到了 A
B
循环援用的场景:
class A {@inject(B) b;
value = "a";
hello() {console.log("a:", this.b.value);
}
}
class B {@inject(A) a;
value = "b";
hello() {console.log("b:", this.a.value);
}
}
从代码执行角度来看,应该都能够失常执行 a.hello()
与 b.hello()
才对,因为尽管 A
B
各自循环援用了,但他们的 value
并没有形成循环依赖,只有能提前拿到他们的值,输入天然不该有问题。
但依赖注入框架遇到了一个难题,初始化 A
依赖 B
,初始化 B
依赖 A
,让咱们看看 spring 三级缓存的实现思路:
spring 三级缓存的含意别离为:
一级缓存 | 二级缓存 | 三级缓存 |
---|---|---|
实例 | 半成品实例 | 工厂类 |
- 实例:实例化 + 实现依赖注入初始化的实例.
- 半成品实例:仅实现了实例化。
- 工厂类:生成半成品实例的工厂。
先说流程,当 A
B
循环依赖时,框架会依照随机程序初始化,假如先初始化 A
时:
一:寻找实例 A
,但一二三级缓存都没有,因而初始化 A
,此时只有一个地址,增加到三级缓存。
堆栈:A。
一级缓存 | 二级缓存 | 三级缓存 | |
---|---|---|---|
模块 A | ✓ | ||
模块 B |
二:发现实例 A
依赖实例 B
,寻找实例 B
,但一二三级缓存都没有,因而初始化 B
,此时只有一个地址,增加到三级缓存。
堆栈:A->B。
一级缓存 | 二级缓存 | 三级缓存 | |
---|---|---|---|
模块 A | ✓ | ||
模块 B | ✓ |
三:发现实例 B
依赖实例 A
,寻找实例 A
,因为三级缓存找到,因而执行三级缓存生成二级缓存。
堆栈:A->B->A。
一级缓存 | 二级缓存 | 三级缓存 | |
---|---|---|---|
模块 A | ✓ | ✓ | |
模块 B | ✓ |
四:因为实例 A
的二级缓存已被找到,因而实例 B
实现了初始化(堆栈变为 A->B),压入一级缓存,并清空三级缓存。
堆栈:A。
一级缓存 | 二级缓存 | 三级缓存 | |
---|---|---|---|
模块 A | ✓ | ✓ | |
模块 B | ✓ |
五:因为实例 A
依赖实例 B
的一级缓存被找到,因而实例 A
实现了初始化,压入一级缓存,并清空三级缓存。
堆栈:空。
一级缓存 | 二级缓存 | 三级缓存 | |
---|---|---|---|
模块 A | ✓ | ||
模块 B | ✓ |
总结
依赖注入实质是将函数的外部实现形象为参数,带来更好的测试性与可维护性,其中可维护性是“只有申明依赖,而不须要关怀如何实例化带来的”,同时主动初始化容器也升高了心智累赘。但最大的奉献还是带来了自上而下的编程思维形式。
依赖注入因为其神奇的个性,须要解决循环依赖问题,这也是面试常问的点,须要牢记。
探讨地址是:精读《依赖注入简介》· Issue #440 · dt-fe/weekly
如果你想参加探讨,请 点击这里,每周都有新的主题,周末或周一公布。前端精读 – 帮你筛选靠谱的内容。
关注 前端精读微信公众号
<img width=200 src=”https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg”>
版权申明:自在转载 - 非商用 - 非衍生 - 放弃署名(创意共享 3.0 许可证)