精读文章：[Dependency Injection in JS/TS – Part 1](https://blog.codeminer42.com/dependency-injection-in-js-ts-part-1/)

## 概述

**依赖注入是将函数内部实现抽象为参数，使我们更方便控制这些它们。**

原文按照 “如何解决无法做单测的问题、统一依赖注入的入口、如何自动保证依赖顺序正确、循环依赖怎么解决、自上而下 vs 自下而上编程思维” 的思路，将依赖注入从想法起点，到延伸出来的特性连贯的串了起来。

### 如何解决无法做单测的问题

如果一个函数内容实现是随机函数，如何做测试？

```js
export const randomNumber = (max: number): number => {
  return Math.floor(Math.random() * (max + 1));
};
```

因为结果不受控制，显然无法做单测，那将 `Math.random` 函数抽象到参数里问题不就解决了！

```js
export type RandomGenerator = () => number;

export const randomNumber = (
  randomGenerator: RandomGenerator,
  max: number
): number => {
  return Math.floor(randomGenerator() * (max + 1));
};
```

但带来了一个新问题：这样破坏了 `randomNumber` 函数本身接口，而且参数变得复杂，不那么易用了。

### 工厂函数 + 实例模式

为了方便业务代码调用，同时导出工厂函数和方便业务用的实例不就行了！

```js
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` 实现，用起来也是比较自然的。

只要每个文件都遵循这种双导出模式，且业务实现除了传递参数外不要有额外的逻辑，这种代码就能同时解决单测与业务问题。

但带来了一个新问题：代码中同时存在工厂函数与实例，即同时构建与使用，这样职责不清晰，而且因为每个文件都要提前引用依赖，依赖间容易形成循环引用，即便上从具体函数层面看，并没有发生函数间的循环引用。

### 统一依赖注入的入口

用一个统一入口收集依赖就能解决该问题：

```js
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。

### 如何自动保证依赖顺序正确

那有没有办法固定依赖注入的模板逻辑，让其被调用时自动根据依赖关系来初始化呢？答案是有的，而且非常的漂亮：

```js
// 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]` 访问的函数，都会在调用时才被初始化，它们会经历这样的处理链条：

1. 初始化 `container` 为空，不提供任何函数，也没有执行任何 `factory`。
2. 当业务代码调用 `container.randomNumber` 时，触发 `get()`，此时会执行 `randomNumber` 的 `factory` 并将 `container` 传入。
3. 如果 `randomNumber` 的 `factory` 没有用到任何依赖，那么 `container` 的子 key 并不会被访问，`randomNumber` 函数就成功创建了，流程结束。
4. 关键步骤来了，如果 `randomNumber` 的 `factory` 用到了任何依赖，假设依赖是它自己，那么会陷入死循环，这是代码逻辑错误，报错是应该的；如果依赖是别人，**假设调用了 `container.abc`，那么会触发 `abc` 所在的 `get()`，重复第 2 步，直到 `abc` 的 `factory` 被成功执行，这样就成功拿到了依赖**

很神奇，固定的代码逻辑竟然会根据访问链路自动嗅探依赖树，并用正确的顺序，从没有依赖的那个模块开始执行 `factory`，一层层往上，直到顶部包的依赖全部构建完成。其中每一条子模块的构建链路和主模块都是分型的，非常优美。

### 循环依赖怎么解决

这倒不是说如何解决函数循环依赖问题，因为：

- 如果函数 a 依赖了函数 b，而函数 b 又依赖了函数 a，这个相当于 a 依赖了自身，神仙都救不了，如果循环依赖能解决，就和声明发明了永动机一样夸张，所以该场景不用考虑解决。
- 依赖注入让模块之间不引用，所以不存在函数间循环依赖问题。

为什么说 a 依赖了自身连神仙都救不了呢？

- a 的实现依赖 a，要知道 a 的逻辑，得先了解依赖项 a 的逻辑。
- 依赖项 a 的逻辑无从寻找，因为我们正在实现 a，这样递归下去会死循环。

那依赖注入还需要解决循环依赖问题吗？需要，比如下面代码：

```js
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` 循环引用的场景：

```js
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](https://github.com/dt-fe/weekly/issues/440)

**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**

> 关注 **前端精读微信公众号**

<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">

> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）