今天完成的事情：

依赖注入是重要的程序设计模式。 Angular 有自己的依赖注入框架，离开了它，几乎没法构建 Angular 应用。 它使用得非常广泛，以至于几乎每个人都会把它简称为 DI。

export class Car {

  public engine: Engine;

  public tires: Tires;

  public description = 'No DI';

  constructor() {

    this.engine = new Engine();

    this.tires = new Tires();

  }

  // Method using the engine and tires

  drive() {

    return `${this.description} car with ` +

      `${this.engine.cylinders} cylinders and ${this.tires.make} tires.`;

  }

Car类会在它的构造函数中创建所需的每样东西。 问题何在？

问题在于，这个Car类过于脆弱、缺乏弹性并且难以测试。

Car类需要一个引擎 (engine) 和一些轮胎 (tire)，它没有去请求现成的实例， 而是在构造函数中用具体的Engine和Tires类实例化出自己的副本。

如果Engine类升级了，它的构造函数要求传入一个参数，这该怎么办？ 这个Car类就被破坏了，在把创建引擎的代码重写为this.engine = new Engine(theNewParameter)之前，它都是坏的。 当第一次写Car类时，我们不关心Engine构造函数的参数，现在也不想关心。 但是，当Engine类的定义发生变化时，就不得不在乎了，Car类也不得不跟着改变。 这就会让Car类过于脆弱。

如果想在Car上使用不同品牌的轮胎会怎样？太糟了。 我们被锁定在Tires类创建时使用的那个品牌上。这让Car类缺乏弹性。

现在，每辆车都有它自己的引擎。它不能和其它车辆共享引擎。 虽然这对于汽车来说还算可以理解，但是设想一下那些应该被共享的依赖，比如用来联系厂家服务中心的车载无线电。 我们的车缺乏必要的弹性，无法共享当初给其它消费者创建的车载无线电。

当给Car类写测试的时候，我们就会受制于它背后的那些依赖。 能在测试环境中成功创建新的Engine吗？ Engine自己又依赖什么？那些依赖本身又依赖什么？ Engine的新实例会发起到服务器的异步调用吗？ 我们当然不想在测试期间这么一层层追下去。

如果Car应该在轮胎气压低的时候闪动警示灯该怎么办？ 如果没法在测试期间换上一个低气压的轮胎，那该如何确认它能正确的闪警示灯？

我们没法控制这辆车背后隐藏的依赖。 当不能控制依赖时，类就会变得难以测试。

该如何让Car更强壮、有弹性以及可测试？

明天计划的事情：

‍‍study angular2‍‍
遇到的问题：

陡峭的学习曲线。
收获：

ng serve --prod --aot 最小压缩ng2启用

ng build --prod --aot 最小化生成

github.com/modern-javascript/angular2-data-flow 单向数据绑定demo

ng serve --proxy-config proxy.conf.json

{{}}双大括号是Angular中的插值表达式绑定语法