AngularJS中的依赖注入实际应用场景有哪些functionPetKeeper(pet){
this.pet=pet;
}
PetKeeper.prototype.feed=function(food){
this.pet.eat(food);
};
functionPet(type){
this.type=type;
}
Pet.prototype.eat=function(food){
alert(“Iama”+this.type+”,I’meating”+food);
};
vartom=newPet(“cat”);
varjerry=newPet(“mouse”);
varkeeper=newPetKeeper(tom);
keeper.feed(“fish”);
keeper.pet=jerry;
keeper.feed(“rice”);
这个例子里，pet是外部注入的，在feed函数定义里，并不知道pet到底是什么（在带接口的语言里，至少还是知道是个什么，在动态语言里就是两眼一抹黑了……），只有当它被调用的时候，才知道pet是什么。
这个过程的好处是什么呢？如果大家在PetKeeper内部去创建tom或jerry，就表示PetKeeper要对Pet产生依赖。一个对别人有依赖的东西，它想要单独测试，就需要在依赖项齐备的情况下进行。如果大家在运行时注入，就可以减少这种依赖，比如在单元测试的时候使用模拟类就行。
比如你有一个a，依赖于b，实际业务中，b的实现很复杂：
functionA(b){
this.b=b;
}
A.prototype.a1=function(){
alert(100+this.b.b1());
};
functionB(){}
B.prototype.b1=function(){
//这里可能很复杂而且不好模拟，比如依赖于生产环境的一些调用
}
那么，偶如何用单元测试来验证A自身的逻辑是正确的呢？如果有强依赖，这里就不好办了，必须实例化真正的B，但是B的调用要依赖于生产环境。换个方式考虑，大家用一个接口与B相同的类来做模拟，只要改变它的返回值，实现各种边界条件，把它的实例注入到A的构造函数中，就可以让A自身的逻辑得到测试了。
functionMockB(){}
MockB.prototype.b1=function(){
return99;
};
在AngularJS里，依赖注入的目的是为了减少组件间的耦合，它的实现是这个过程：
functionArt(Bar,Car){}
偶怎么知道这个Art在实例化的时候要传入Bar和Car的实例呢？形参名称是没法取到的，所以只有狠一点，用toString()来取到刚才这一行字符串，然后用正则表达式取到Bar和Car这两个字符串，然后到模块映射中取到对应的模块，实例化之后传入。
但是这样也有问题，如果这个js被压缩了，很可能命名都变了，压缩成了这样：
functiona1(b1,b2){}
这时候再这样就不知道原先是什么类型了。在这里，有类型声明的语言就不会有问题，比如：
functionart(bar:Bar,car:Car):Art{}
就算你把art,bar,car都改名了，也还是能知道类型，但js里不行。所以，怎么办呢？
aaa.controller(“Art”,[function(Bar,Car){},”Bar”,”Car”]);
注意在AngularJS里面，他很可能建议你这么写，但也可以这么写：
Art.$inject=[“Bar”,”Car”];
这么一来，偶只要拿到Art，就能取到依赖项的名称了，就可以实例化再注入，也不怕压缩了。