anchor.diff:      We don't import them elsewhere so they're not _shared_ in that sense. 
       Yet they're too big and messy to leave loose in the root folder.
   
  +    但真实的应用要考虑很多。
  +    它们有很多一次性的组件（比如：加载动画、消息浮层和模态对话框等），而且只用于`AppComponent`的模板中。
  +    我们不用在其它地方导入它们，因此没必要*共享*它们。
  +    然而如果把它们留在根目录，还是显得太大、太乱了。
  +
       Apps often have many singleton services like this sample's `UserService`.
       Each must be registered _exactly once_, in the app root injector, when the application starts.
  +    
  +    应用通常还有很多像这里的`UserService`这样的单例服务。
  +    当程序启动时，每一个服务都只能在应用的“根注入器”中*注册一次*。
   
       While many Components inject such services in their constructors &mdash;
       and therefore require JavaScript `import` statements to import their symbols &mdash;
       no other component or module should define or re-create the services themselves.
       Their _providers_ are not shared.
  +    
  +    当很多组件在它们的构造函数中注入这些服务时（因此也需要用JavaScript的`import`语句来导入它们的符号），任何组件或模块自身都不应该定义或重新创建这些服务。
  +    它们的*提供商*不是共享的。
   
       We recommend collecting such single-use classes and hiding their gory details inside a `CoreModule`.
       A simplified root `AppModule` imports `CoreModule` in its capacity as orchestrator of the application as a whole.
   
  +    因此我们建议把这些一次性的类收集到`CoreModule`中，并且隐藏它们的实现细节。
  +    简化之后的根模块`AppModule`导入`CoreModule`来获取其能力。记住，根模块是整个应用的总指挥，不应该插手过多细节。
  +
   .l-main-section
   :marked
     ## Cleanup
  +  ## 清理
  +
     Having refactored to a `CoreModule` and a `SharedModule`, it's time to cleanup the other modules. 
   
  +  我们已经重构完了`CoreModule`和`SharedModule`，该开始清理其它模块了。
  +
     ### A trimmer _AppModule_
     
  +  ### 清理*AppModule*
  +  
     Here is the updated `AppModule` paired with version 3 for comparison:
  +  
  +  这里是更新后的`AppModule`与其第三个版本的对比：
  +
   +makeTabs(
     `ngmodule/ts/app/app.module.ts,
      ngmodule/ts/app/app.module.3.ts`,
  
positive.code:   or an editor of a selected hero (`HeroDetail`).
    Both components delegate to the `HeroService` to fetch and save data.
  
    There's yet _another_ `HighlightDirective` that colors elements in yet a different shade.
    We should [do something](#shared-module "Shared modules") about the repetition and inconsistencies.
    We endure for now.
  
    The `HeroModule` is a feature module like any other.
  +makeExample('ngmodule/ts/app/hero/hero.module.3.ts', 'class', 'app/hero/hero.module.ts (class)')(format='.')
  :marked
    It imports the `FormsModule` because the `HeroDetailComponent` template binds with `[(ngModel)]`. 
    It imports a `routing` object from `hero.routing.ts` just as `ContactModule` and `CrisisModule` do.
  
    The `CrisisModule` is much the same. There's nothing more to say that's new. 
  
    <live-example embedded plnkr="pre-shared.3" img="devguide/ngmodule/v3-plunker.png">Try the live example.</live-example>
  
  a#shared-module
  .l-main-section
  :marked
    ## Shared modules
    
    The app is shaping up. 
    One thing we don't like is carrying three different versions of the `HighlightDirective`.
    And there's a bunch of other stuff cluttering the app folder level that could be tucked away.
  
    Let's add a `SharedModule` to hold the common components, directives, and pipes 
    and share them with the modules that need them.
  
    * create an `app/shared` folder
    * move the `AwesomePipe` and `HighlightDirective` from `app/contact` to `app/shared`.
    * delete the `HighlightDirective` classes from `app/` and `app/hero`
    * create a `SharedModule` class to own the shared material
    * update other feature modules to import `SharedModule`
  
    Most of this is familiar blocking and tackling. Here is the `SharedModule`
  +makeExample('ngmodule/ts/app/shared/shared.module.ts', '', 'app/app/shared/shared.module.ts')
  :marked
    Some highlights
    * It imports the `CommonModule` because its component needs common directives.
    * It declares and exports the utility pipe, directive, and component classes as expected.
    * It re-exports the `CommonModule` and `FormsModule`
  
    #### Re-exporting other modules
  
    While reviewing our application, we noticed that many components requiring `SharedModule` directives
    also use `NgIf` and `NgFor` from `CommonModule`
    and bind to component properties with `[(ngModel)]`, a directive in the `FormsModule`.
    Modules that declare these components would have to import `CommonModule`, `FormsModule` and `SharedModule`.
  
    We can reduce the repetition by having `SharedModule` re-export `CommonModule` and `FormsModule`
    so that importers of `SharedModule` get `CommonModule` and `FormsModule` _for free_.
  
    As it happens, the components declared by `SharedModule` itself don't bind with `[(ngModel)]`. 
    Technically,  there is no need for `SharedModule` to import `FormsModule`.
    
    `SharedModule` can still export `FormsModule` without listing it among its `imports`.
  
    ### Why _TitleComponent_ isn't shared
  
    `SharedModule` exists to make commonly used components, directives and pipes available
    for use in the templates of components in _many_ other modules.
  
    The `TitleComponent` is used _only once_ by the `AppComponent`. 
    There's no point in sharing it.
  
    <a id="no-shared-module-providers"></a>
    ### Why _UserService_ isn't shared  
  
    While many components share the same service _instances_,
    they rely on Angular dependency injection to do this kind of sharing, not the module system.
   
    Several components of our sample inject the `UserService`.
    There should be _only one_ instance of the `UserService` in the entire application 
    and _only one_ provider of it.
    
    `UserService` is an application-wide singleton.
    We don't want each module to have its own separate instance. 
    Yet there is [a real danger](../cookbook/ngmodule-faq.html#q-why-it-is-bad) of that happening 
    if the `SharedModule` provides the `UserService`.
  
  .alert.is-critical
    :marked
      Do **not** specify app-wide singleton `providers` in a shared module.
      A lazy loaded module that imports that shared module will make its own copy of the service.
  
  a#core-module
  .l-main-section
  :marked
    ## The Core module
    At the moment, our root folder is cluttered with the `UserService`
    and the `TitleComponent` that only appears in the root `AppComponent`.
    We did not include them in the `SharedModule` for reasons just explained.
    
    Instead, we'll gather them in a single `CoreModule` that we **import _once_ when the app starts**
    and _never import anywhere else_.
  
    **Steps:**
  
    * create an `app/core` folder
    * move the `UserService` and `TitleComponent` from `app/` to `app/core`
    * create a `CoreModule` class to own the core material
    * update the `AppRoot` module to  import `CoreModule`
    
    Again, most of this is familiar blocking and tackling. The interesting part is the `CoreModule`
  +makeExample('ngmodule/ts/app/core/core.module.ts', 'v4', 'app/app/core/core.module.ts')
  .l-sub-section
    :marked
      We're importing some extra symbols from the Angular core library that we're not using yet.
      They'll become relevant later in this page.
  :marked
    The `@NgModule` metadata should be familiar. 
    We declare the `TitleComponent`  because this module _owns_ it and we export it
    because `AppComponent` (which is in `AppModule`) displays the title in its template.
    `TitleComponent` needs the Angular `NgIf` directive that we import from `CommonModule`.
  
    `CoreModule` _provides_ the `UserService`. Angular registers that provider with the app root injector,
    making a singleton instance of the `UserService` available to any component that needs it, 
    whether that component is eagerly or lazily loaded.
  
  .l-sub-section
    :marked
      #### Why bother?
      This scenario is clearly contrived. 
      The app is too small to worry about a single service file and a tiny, one-time component.
  
      A `TitleComponent` sitting in the root folder isn't bothering anyone.
      The root `AppModule` can register the `UserService` itself,
      as it does currently, even if we decide to relocate the `UserService` file to the `app/core` folder.
  
      Real world apps have more to worry about. 
      They can have several single-use components (e.g., spinners, message toasts, and modal dialogs)
  
negative.code: 
  :marked
    Notice that `AppModule` is ...
    
    注意`AppModule`已经变得：
    
    * a little smaller because many `app/root` classes have moved to other modules.
    * 更小了。因为很多`app/root`下的类被移到了其它模块中。
    * stable because we'll add future components and providers to other modules, not this one.
    * 更稳定了。因为我们以后会在其它模块中添加组件和服务提供商，而不是这里。
    * delegating to imported modules rather than doing work.
    * 导入其它模块并把任务委托给它们，而不是亲力亲为。
    * focused on its main task, orchestrating the app as a whole.
    * 聚焦于自己的主要任务，整个应用程序的总指挥。
  
    ### A trimmer _ContactModule_
    ### 清理*ContactModule*
    
    Here is the new `ContactModule` paired with the prior version:
    
    这里是新的`ContactModule`与以前版本的对比：
  
  +makeTabs(
    `ngmodule/ts/app/contact/contact.module.ts,
     ngmodule/ts/app/contact/contact.module.3.ts`,
  