关于javascript:精读依赖注入简介

精读文章：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] 拜访的函数，都会在调用时才被初始化，它们会经验这样的解决链条：

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，这样递归上来会死循环。

那依赖注入还须要解决循环依赖问题吗？须要，比方上面代码：

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，寻找实例 B，但一二三级缓存都没有，因而初始化 B，此时只有一个地址，增加到三级缓存。
堆栈：A->B。

三：发现实例 B 依赖实例 A，寻找实例 A，因为三级缓存找到，因而执行三级缓存生成二级缓存。
堆栈：A->B->A。

四：因为实例 A 的二级缓存已被找到，因而实例 B 实现了初始化（堆栈变为 A->B），压入一级缓存，并清空三级缓存。
堆栈：A。

五：因为实例 A 依赖实例 B 的一级缓存被找到，因而实例 A 实现了初始化，压入一级缓存，并清空三级缓存。
堆栈：空。

总结

依赖注入实质是将函数的外部实现形象为参数，带来更好的测试性与可维护性，其中可维护性是“只有申明依赖，而不须要关怀如何实例化带来的”，同时主动初始化容器也升高了心智累赘。但最大的奉献还是带来了自上而下的编程思维形式。

依赖注入因为其神奇的个性，须要解决循环依赖问题，这也是面试常问的点，须要牢记。

探讨地址是：精读《依赖注入简介》· Issue #440 · dt-fe/weekly

如果你想参加探讨，请 点击这里，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。

关注 前端精读微信公众号

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

版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）