我真正喜欢成熟框架的一点就是它们都实现了某种依赖注入。最近我一直在钻研 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>(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<T> {
new(...args: any[]): T;
}
Type<T> 能够让我们知道对象的原型是什么？或者换句话说：当我们使用 new 后拿到的是什么。回头看看我们的 @Service 装饰器，真正的目标类型应该是：
const Service = () : ClassDecorator => {
return target => {
// `target` in this case is `Type<Foo>`, not `Foo`
};
};
让我困扰的一个点是 ClassDecorator，它看起来像这样：
declare type ClassDecorator = <TFunction extends Function>(target: TFunction) => TFunction | void;
不幸的是，因为我们现在的确知道对象的类型，要为类装饰器获得一个更灵活更通用的类型。
export type GenericClassDecorator<T> = (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<Type<object>> => {
return (target: Type<object>) => {
// do something with `target`, e.g. some kind of validation or passing it to the Injector and store them
};
};
Injector
Injector 主要用于解析实例。它可能也具备其他能力如存储解析后的实例（我比较喜欢将它们称为共享实例），但为了简单起见，我们现在将尽可能简单的实现。
// Injector.ts
export const Injector = new class {
// Injector implementation
};
导出 const 而非 class（比如 export class Injector） 的原因在于我们的 Injector 是单例的。否则，我们将永远无法得到相同的 Injector 实例，这意味着任何时候你引入 Injector 所得到的实例都是未注册过服务的。（像所有单例一样也存在一些缺点，尤其在测试方面）
下一步我们需要实现一个方法来解析实例：
// Injector.ts
export const Injector = new class {
// resolving instances
resolve<T>(target: Type<any>): T {
// tokens are required dependencies, while injections are resolved tokens from the Injector
let tokens = Reflect.getMetadata('design:paramtypes', target) || [],
injections = tokens.map(token => Injector.resolve<any>(token));
return new target(...injections);
}
};
到此为止，我们的 Injector 已经可以解析请求的实例了。让我们回到开头的例子（现在稍微扩展一下），通过 Injector 来解析它：
@Service()
class Foo {
doFooStuff() {
console.log('foo');
}
}
@Service()
class Bar {
constructor(public foo: Foo) {
}
doBarStuff() {
console.log('bar');
}
}
@Service()
class Foobar {
constructor(public foo: Foo, public bar: Bar) {
}
}
const foobar = Injector.resolve<Foobar>(Foobar);
foobar.bar.doBarStuff();
foobar.foo.doFooStuff();
foobar.bar.foo.doFooStuff();
控制台输出：
bar
foo
foo
这意味着我们的 Injector 成功注入了所有依赖项。哇呜！
总结
依赖注入绝对是你应该使用的强大工具。这篇文章是关于依赖注入是如何工作的，给你一些实现自己的 Injector 的灵感。
还有不少事情需要去做，大概举几个例子：
- 错误处理
- 解决循环依赖
- 存储已解析的实例
- 注入比构造函数token更多的能力
- 等等
但基本上，这就是Injector的工作原理。
正如开头所说的，我最近刚开始研究 DI 的实现。如果你对这篇文章或者Injector的实现感到任何困惑，欢迎给我留言或者通过邮件联系我。
跟往常一样，所有的代码（包含示例和测试）都可以在 Github上找到。
