什么是依赖注入

所以依赖注入使程序员的生活更容易，但它真正做什么？

考虑下面的代码：

  1. class Hamburger {
  2.   private bun: Bun;
  3.   private patty: Patty;
  4.   private toppings: Toppings;
  5.   constructor() {
  6.     this.bun = new Bun('withSesameSeeds');
  7.     this.patty = new Patty('beef');
  8.     this.toppings = new Toppings(['lettuce', 'pickle', 'tomato']);
  9.   }
  10. }

上面的代码是一个表示一个汉堡包类。 该类假设汉堡包括Bun, Patty 和 Toppings。 该类还负责制作Bun, Patty 和 Toppings。 这是一件坏事。 如果需要素食汉堡怎么办？ 一个天真的方法可能是：

  1. class VeggieHamburger {
  2.   private bun: Bun;
  3.   private patty: Patty;
  4.   private toppings: Toppings;
  5.   constructor() {
  6.     this.bun = new Bun('withSesameSeeds');
  7.     this.patty = new Patty('tofu');
  8.     this.toppings = new Toppings(['lettuce', 'pickle', 'tomato']);
  9.   }
  10. }

有，问题解决了吗？ 但是如果我们需要一个无麸质汉堡包呢？ 如果我们想要不同的Toppings…如果是更通用的东西如：

  1. class Hamburger {
  2.   private bun: Bun;
  3.   private patty: Patty;
  4.   private toppings: Toppings;
  5.   constructor(bunType: string, pattyType: string, toppings: string[]) {
  6.     this.bun = new Bun(bunType);
  7.     this.patty = new Patty(pattyType);
  8.     this.toppings = new Toppings(toppings);
  9.   }
  10. }

好吧，这有点不同，它在某些方面更灵活，但它仍然相当脆弱。 如果Patty构造函数改变以允许新的功能会发生什么？ 整个汉堡包类必须更新。 事实上，任何时候任何这些在汉堡的构造函数中使用的构造函数都会改变，汉堡包也必须改变。

此外，测试期间会发生什么？ 如何有效地mocked Bun, Patty 和 Toppings？

考虑这些关注，类可以重写为：

  1. class Hamburger {
  2.   private bun: Bun;
  3.   private patty: Patty;
  4.   private toppings: Toppings;
  5.   constructor(bun: Bun, patty: Patty, toppings: Toppings) {
  6.     this.bun = bun;
  7.     this.patty = patty;
  8.     this.toppings = toppings;
  9.   }
  10. }

现在当汉堡实例化时，它不需要知道关于它的 Bun, Patty 和 Toppings。 这些元素的构建已经被移出类了。 这种模式非常常见以至于TypeScript允许将他它简写成如下形式：

  1. class Hamburger {
  2.   constructor(private bun: Bun, private patty: Patty, 
  3.     private toppings: Toppings) {}
  4. }

汉堡包类现在更简单，更容易测试。 这种将依赖项提供给Hamburger的模型是基本的依赖注入。

但是还是有一个问题。 如何管理Bun，Patty和Toppings的实例化？

这是依赖注入作为框架可以使程序员受益的地方，它是Angular 2提供的依赖注入系统。