TypeScript 中的依赖注入（译）

我真正喜欢成熟框架的一点就是它们都实现了某种依赖注入。最近我一直在钻研 TypeScript 这门技术，以便更好地从表面上理解它是如何工作的。

---

什么是依赖注入 (DI)？

如果你还不了解什么是 依赖注入，我强烈推荐你了解一下。既然这篇文章不是来介绍什么是 DI 的，更多地是讲 DI 是如何实现的，我们尽量用简单点的话来描述它：

依赖注入是一种通过外部注入来表明对象的依赖关系的技术。

什么意思呢？原本我们通过各种参数来构造对象，现在只需接收一个已实例化的对象。

想象以下代码：

class Foo {
}

class Bar {
  foo: Foo;
  
  constructor() {
    this.foo = new Foo();
  }
}

class Foobar {
  foo: Foo;
  bar: Bar;
  
  constructor() {
    this.foo = new Foo();
    this.bar = new Bar();
  }
}

Bad.

这段代码带来很多弊端，由于类之间存在了直接和不可替换的依赖关系，会使代码难以测试，可用性和复用性极差。而通过依赖注入的方式，将依赖项注入到你的构造函数中，可以很好地解决这些弊端。

class Foo {
}

class Bar {
  constructor(foo: Foo) {
  }
}

class Foobar {
  constructor(foo: Foo, bar: Bar) {
  }
}

Better.

初始化 Foobar 实例你需要通过以下方式：

const foobar = new Foobar(new Foo(), new Bar(new Foo()));

Not cool.

通过 Injector 来创建对象，你可以简单地这样写：

const foobar = Injector.resolve(Foobar); // returns an instance of Foobar, with all injected dependencies

Better.

为什么要使用依赖注入的原因有很多，包括可测试行，可维护性，可读性等等。再说一遍，如果你还不了解它，那么很有必要去学习一下了。

TypeScript 中的依赖注入

这篇文章将介绍我们自己实现的（非常基础的）Injector 。如果你只是想找一些现有 DI 解决方案来运用到你的项目中的话，建议你看看 InversifyJS，它是一个很好的控制反转(IoC) 的 TypeScript 库。

在本文中，我们将会实现自己的 Injector 类，该类能够通过注入所有必需的依赖项来解析实例。为此我们将实现一个 @Service 的装饰器（如果你用过 Angular 的话可能知道 @Injectable）来定义我们的服务以及解析实际实例的 Injector。

在具体实现之前，你看你需要先了解有关 TypeScript 和 DI 的一些知识：

反射和装饰

我们将使用 reflect-metadata 包来获取运行时的反射功能 。通过这个包可以了解一个类是如何实现的 - 例如：

const Service = () : ClassDecorator => {
  return target => {
    console.log(Reflect.getMetadata('design:paramtypes', target));
  };
};

class Bar {}

@Service()
class Foo {
  constructor(bar: Bar, baz: string) {}
}

控制台将输出以下日志：

[ [Function: Bar], [Function: String] ]

因此我们确实知道需要注入的依赖项是什么。如果你对这里的 Bar 是一个 Function 感到困惑：我将在下一个章节中介绍。

重要提示：必须注意的是，没有装饰器的类是没有任何 metadata 的，这似乎是 reflect-metadata 的设计选择，尽管我不确定其背后的原因。

target 的类型

有个让我非常困惑的地方是 Service 中的 target 的类型。它很明显是个 object 而非 Function 呀，但这是因为在 Javascript 中，类实际上就是一个特殊的函数：

class Foo {
    constructor() {
        // the constructor
    }
    bar() {
        // a method
    }
}

转变：

var Foo = /** @class */ (function () {
    function Foo() {
        // the constructor
    }
    Foo.prototype.bar = function () {
        // a method
    };
    return Foo;
}());

编译后代码

但 Function 显然不是我们想要的目标类型，因为它太泛了。由于我们现在还没有真正使用一个实例，我们需要得到通过 new 创建的实例的确切类型：

interface Type {
  new(...args: any[]): T;
}

Type 能够让我们知道对象的原型是什么？或者换句话说：当我们使用 new 后拿到的是什么。回头看看我们的 @Service 装饰器，真正的目标类型应该是：

const Service = () : ClassDecorator => {
  return target => {
    // `target` in this case is `Type`, not `Foo`
  };
};

让我困扰的一个点是 ClassDecorator，它看起来像这样：

declare type ClassDecorator = (target: TFunction) => TFunction | void;

不幸的是，因为我们现在的确知道对象的类型，要为类装饰器获得一个更灵活更通用的类型。

export type GenericClassDecorator = (target: T) => void;

编译后 interface 不见了

由于接口不是 Javascript 的一部分，所以 TypeScript 编译后它们就消失了。这并不是什么新鲜事，但这意味着我们不能使用接口进行依赖注入。举个例子：

interface LoggerInterface {
  write(message: string);
}

class Server {
  constructor(logger: LoggerInterface) {
    this.logger.write('Service called');
  }
}

由于接口在运行时不可用，所以我们的 Injector 将无法知道要注入什么。

这实在是个遗憾，因为这意味着我们总是必须通过类型提示来替代接口。特别是在我们进行测试的时候非常不好。

还有一些解决方法，比如通过类而不是接口（感觉很奇怪，丧失了接口的意义）或者像这样：

interface LoggerInterface {
  kind: 'logger';
}

class FileLogger implements LoggerInterface {
  kind: 'logger';
}

然而我真的不喜欢这种方法，因为它又冗长又难看。

循环依赖带来的麻烦

如果你试图这样做：

@Service()
class Bar {
  constructor(foo: Foo) {}
}

@Service()
class Foo {
  constructor(bar: Bar) {}
}

你将会得到一个 ReferenceError ，告诉你：

ReferenceError: Foo is not defined 

原因很明显：TypeScript 在解释 Bar 的时候， Foo 还不存在。

我不想在这里细究，但有一个可能的解决方法是实现类似 Angular 的 forwardRef 方法。

实现我们自己的 Injector

好了，理论讲得差不多了。让我们实现一个非常基础的 Injector 类吧。

我们将使用以上学到的所有知识，来开始我们的 @Service 装饰器。

@Service 装饰器

我们将会对所有服务进行装饰处理，否则他们将无法返回元数据（就无法注入依赖项了）。

// ServiceDecorator.ts

const Service = () : GenericClassDecorator> => {
  return (target: Type