anchor.diff:    :marked
       The code for this _cars_ scenario is in the `car.components.ts` and `car.services.ts` files of the sample
       which you can review and download from the <live-example></live-example>.
  +    
  +    *车辆*场景下的代码位于`car.components.ts`和`car.services.ts`文件中，这个例子你可以在<live-example></live-example>查看和下载。
  +    
   //- ## Advanced Dependency Injection in Angular
   //- Restrict Dependency Lookups
   //- [TODO] (@Host) This has been postponed for now until we come up with a decent use case
  
positive.code:   Recall that every component _instance_ has its own injector.
    Providing the service at the component level ensures that _every_ instance of the component gets its own, private instance of the service.
    No tax return overwriting. No mess.
  
  .l-sub-section
    :marked
      The rest of the scenario code relies on other Angular features and techniques that you can learn about elsewhere in the documentation.
      You can review it and download it from the <live-example></live-example>.
  
  :marked
    ### Scenario: specialized providers
  
    Another reason to re-provide a service is to substitute a _more specialized_ implementation of that service,
    deeper in the component tree.
  
    Consider again the Car example from the [Dependency Injection](./dependency-injection.html) guide.
    Suppose you configured the root injector (marked as A) with _generic_ providers for
    `CarService`, `EngineService` and `TiresService`.
  
    You create a car component (A) that displays a car constructed from these three generic services.
  
    Then you create a child component (B) that defines its own, _specialized_ providers for `CarService` and `EngineService`
    that have special capabilites suitable for whatever is going on in component (B).
  
    Component (B) is the parent of another component (C) that defines its own, even _more specialized_ provider for `CarService`.
  
  figure.image-display
    img(src="/resources/images/devguide/dependency-injection/car-components.png" alt="car components" width="220")
  
  :marked
    Behind the scenes, each component sets up its own injector with zero, one, or more providers defined for that component itself.
  
    When you resolve an instance of `Car` at the deepest component (C),
    its injector produces an instance of `Car` resolved by injector (C) with an `Engine` resolved by injector (B) and
    `Tires` resolved by the root injector (A).
  
  figure.image-display
    img(src="/resources/images/devguide/dependency-injection/injector-tree.png" alt="car injector tree" width="600")
  
negative.code:   The setter initializes the component's own instance of the `HeroTaxReturnService` with the incoming return.
    The getter always returns what that service says is the current state of the hero.
    The component also asks the service to save and restore this tax return.
    
    我们通过输入属性得到*要编辑的报税单*，我们把它实现成了读取器（getter）和设置器（setter）。
    设置器根据传进来的报税单初始化了组件自己的`HeroTaxReturnService`实例。
    读取器总是返回该服务所存英雄的当前状态。
    组件也会请求该服务来保存或还原这个报税单。
  
    There'd be big trouble if _this_ service were an application-wide singleton.
    Every component would share the same service instance.
    Each component would overwrite the tax return that belonged to another hero.
    What a mess!
    
    这里有个大问题，那就是如果*这个*服务是一个全应用范围的单例，每个组件就都会共享同一个服务实例，每个组件也都会覆盖属于其他英雄的报税单，真是一团糟！
  
    Look closely at the metadata for the `HeroTaxReturnComponent`. Notice the `providers` property.
    
    但仔细看`HeroTaxReturnComponent`的元数据，注意`providers`属性。
  
  +makeExcerpt('src/app/hero-tax-return.component.ts', 'providers', '')
  
  