anchor.diff:    These two examples cover our needs for an app with one level routing.
     The moment we add a child router, such as the *Crisis Center*, we create new link array possibilities.
   
  -  这两个例子覆盖了我们在单级路由的应用中所需的一切。该添加一个子路由了，就像在*危机中心*中，我们创建新链接数组那样。
  +  这两个例子覆盖了我们在单级路由的应用中所需的一切。在添加一个像*危机中心*一样的子路由时，我们创建新链接数组组合。
   
     Recall that we specified a default child route for *Crisis Center* so this simple `RouterLink` is fine.
   
  
positive.code:     as long as the URL can be emailed and pasted into a browser address bar
      as this one can.
  
      对我们来说，这种语法看起来可能有点奇怪，但用户不大可能注意到或关心这一点，因为标准的URL能被邮件出去或传到浏览器地址栏，这种也可以。
  
  <a id="final-app"></a>
  
  
negative.code:   We did so, for example, in the [HeroDetailComponent](#hero-detail-ctor).
    We might have put the `ngOnInit` logic inside the constructor instead. We didn't for a reason. The reason is *testability*.
  
    我们在很多组件类中实现了`ngOnInit`方法。比如在[HeroDetailComponent](#hero-detail-ctor)中就这么用过。也可以把`ngOnInit`中的逻辑放在构造函数中，但为了一个理由而没那么做，这个理由就是*可测试性*。
  
    A constructor that has major side-effects can be difficult to test because it starts doing things as soon as
    we create a test instance. In this case, it might have made a request to a remote server, something it shouldn't
    do under test. It may even be impossible to reach the server in the test environment.
  
    有显著副作用的构造函数很难测试，因为它在创建测试实例时就开始做事了。这种情况下，它可能已经向远程服务器发起了请求，但有些事情在测试时没法做。可能在测试环境下无法访问服务器。
  
    The better practice is to limit what the constructor can do. Mostly it should stash parameters in
    local variables and perform simple instance configuration.
  