通过依赖注入，函数的执行和其所依赖对象的创建逻辑就被解耦开来了。
当然，随着grunt/gulp/fis等前端工程化工具的普及，越来越多的项目在上线之前都经过了代码混淆(uglify)，因而通过参数名去判断依赖并不总是可靠，有时候也会通过为function添加额外属性的方式来明确地说明其依赖：
Student.prototype.write.depends = ['notebook', 'pencil']; Student.prototype.draw.depends = ['notebook', 'pencil', 'eraser']; Injector.prototype.resolve = function (func, bind) { var self = this; // 首先检查func上是否有depends属性，如果没有，再用正则表达式解析 func.depends = func.depends || self.getParamNames(func); var params = func.depends.map(function (name) { return self._cache[name]; }); func.apply(bind, params); }; var student = new Student(); injector.resolve(student.write, student); // writing... injector.resolve(student.draw, student); // draw...
二. AngularJS中基于双Injector的依赖注入
熟悉AngularJS的同学很快就能联想到，在injector注入之前，我们在定义module时还可以调用config方法来配置随后会被注入的对象。典型的例子就是在使用路由时对$routeProvider的配置。也就是说，不同于上一小节中直接将现成对象（比如new Notebook()）存入cache的做法，AngularJS中的依赖注入应该还有一个”实例化”或者”调用工厂方法”的过程。
这就是providerInjector、instanceInjector以及他们各自所拥有的providerCache和instanceCache的由来。
在AngularJS中，我们能够通过依赖注入获取到的injector通常是instanceInjector，而providerInjector则是以闭包中变量的形式存在的。每当我们需要AngularJS提供依赖注入服务时，比如想要获取notebook，instanceInjector会首先查询instanceCache上是存在notebook属性，如果存在，则直接注入；如果不存在，则将这个任务转交给providerInjector；providerInjector会将”Provider”字符串拼接到”notebook”字符串的后面，组成一个新的键名”notebookProvider”，再到providerCache中查询是否有notebookProvider这个属性，如有没有，则抛出异常Unknown Provider异常：
如果有，则将这个provider返回给instanceInjector；instanceInjector拿到notebookProvider后，会调用notebookProvider上的工厂方法$get，获取返回值notebook对象，将该对象放到instanceCache中以备将来使用，同时也注入到一开始声明这个依赖的函数中。
需要注意的是，AngularJS中的依赖注入方式也是有缺陷的：利用一个instanceInjector单例服务全局的副作用就是无法单独跟踪和控制某一条依赖链条，即使在没有交叉依赖的情况下，不同module中的同名provider也会产生覆盖，这里就不详细展开了。
另外，对于习惯于Java和C#等语言中高级IoC容器的同学来说，看到这里可能觉得有些别扭，毕竟在OOP中，我们通常不会将依赖以参数的形式传递给方法，而是作为属性通过constructor或者setters传递给实例，以实现封装。的确如此，一、二节中的依赖注入方式没有体现出足够的面向对象特性，毕竟这种方式在Javascript已经存在多年了，甚至都不需要ES5的语法支持。希望了解Javascript社区中最近一两年关于依赖注入的研究和成果的同学，可以继续往下阅读。
三. TypeScript中基于装饰器和反射的依赖注入
博主本身对于Javascript的各种方言的学习并不是特别热情，尤其是现在EMCAScript提案、草案更新很快，很多时候借助于polyfill和babel的各种preset就能满足需求了。但是TypeScript是一个例外（当然现在Decorator也已经是提案了，虽然阶段还比较早，但是确实已经有polyfill可以使用）。上文提到，Javascript社区中迟迟没有出现一款优秀的IoC容器和自身的语言特性有关，那就依赖注入这个话题而言，TypeScript给我们带来了什么不同呢？至少有下面这几点：
* TypeScript增加了编译时类型检查，使Javascript具备了一定的静态语言特性
* TypeScript支持装饰器（Decorator）语法，和传统的注解（Annotation）颇为相似
* TypeScript支持元信息（Metadata）反射，不再需要调用Function.prototype.toString方法
下面我们就尝试利用TypeScript带来的新语法来规范和简化依赖注入。这次我们不再向函数或方法中注入依赖了，而是向类的构造函数中注入。
TypeScript支持对类、方法、属性和函数参数进行装饰，这里需要用到的是对类的装饰。继续上面小节中用到的例子，利用TypeScript对代码进行一些重构：
class Pencil { public printName() { console.log('this is a pencil'); } } class Eraser { public printName() { console.log('this is an eraser'); } } class Notebook { public printName() { console.log('this is a notebook'); } } class Student { pencil: Pencil; eraser: Eraser; notebook: Notebook; public constructor(notebook: Notebook, pencil: Pencil, eraser: Eraser) { this.notebook = notebook; this.pencil = pencil; this.eraser = eraser; } public write() { if (!this.notebook || !this.pencil) { throw new Error('Dependencies not provided!'); } console.log('writing...'); } public draw() { if (!this.notebook || !this.pencil || !this.eraser) { throw new Error('Dependencies not provided!'); } console.log('drawing...'); } }