javax.inject

     在我们的程序中，很多类型依赖于其他类型。例如，一个 Stopwatch 可能依赖于一个 TimeSource。一些类型被另一个类型依赖，我们就把这些类型叫做这个类型的依赖（物）
。在运行时查找一个依赖实例的过程叫做解析
依赖
。如果找不到依赖的实例，那我们称该依赖为不能满足的
，并导致应用运行失败。

     在不使用依赖注入时，对象的依赖解析有几种方式。最常见的就是通过编写直接调用构造器的代码完成：

      class Stopwatch {

          final TimeSource timeSource;

          Stopwatch () {

              timeSource = new AtomicClock(...);

          }

          void start() { ... }

          long stop() { ... }

      }

    
如果需要更有弹性一点，那么我们可以通过工厂或服务定位器实现：

         class Stopwatch {

          final TimeSource timeSource;

          Stopwatch () {

              timeSource = DefaultTimeSource.getInstance();

          }

          void start() { ... }

          long stop() { ... }

      }

      在使用这些传统方式进行依赖解析时，程序员必须

做出适当权衡。构造器非常简洁，但却有一些限制（对象生存期，对象复用）。工厂确实解耦了客户与实现，但却需要样本式的代码。

服务定位器更进一步地解耦了客户与实现，但却降低了编译时的类型安全。并且，这三个方式都不适合进行单元测试。例如，当程序员使用工厂时，该工厂的
每一个
产品都必须模拟出来，测试完后还要得记得清理：

          DefaultTimeSource.setInstance(new MockTimeSource());

          try {

              // Now, we can actually test Stopwatch.

              Stopwatch sw = new Stopwatch();

              ...

          } finally {

              DefaultTimeSource.setInstance(original);

          }

      }

     现实中，
要模拟工厂将导致更多的样本式代码。测试模拟出的产品并清理它们在依赖多的情况下很快就控制不了了。更糟的是，程序员必须精确地预测
未来到底需要多少这样的弹性，并为他做的“弹性选择”负责。如果程序员开始时选择了构造器方式，但后来需要一个更有弹性的方式，那他就不得不替换所有调用构造器的代码。
如果程序员一开始过于谨慎地选择了工厂方式，结果可能导致要编写很多额外的样本式代码，引入了不必要的复杂度，潜在的问题比比皆是。

     依赖注入
就是为了解决这些问题。代替程序员调用构造器或工厂，一个称作依赖注入器
的工具将把依赖传递给对象：

      class Stopwatch {

          final TimeSource timeSource;

          @Inject Stopwatch(TimeSource timeSource) {

              this.TimeSource = timeSource;

          }

          void start() { ... }

          long stop() { ... }

      }

     注入器将更进一步地传递依赖给其他的依赖，直到

它

构造出整个

对象图
。
例如，假设一个程序员需要注入器创建一个
StopwatchWidget 实例：

1<span style="FONT-FAMILY:Courier New">&nbsp;class StopwatchWidget {</span>

1<span style="FONT-FAMILY:Courier New">&nbsp;&nbsp;&nbsp;&nbsp; @Inject StopwatchWidget(Stopwatch sw) { ... }</span>

1<span style="FONT-FAMILY:Courier New">&nbsp;&nbsp;&nbsp;&nbsp; ...</span>

1<span style="FONT-FAMILY:Courier New">&nbsp;}</span>

1<br style="FONT-FAMILY:Courier New" />

      void testStopwatch() {

          Stopwatch sw = new Stopwatch(new MockTimeSource());

          ...

      }

     完全降低了单元测试的复杂度，降低的复杂程度与待测对象的数目及其依赖成正比。

      包 javax.inject 为使用这样的轻便类提供了依赖注入注解
，但没有引入依赖配置方式。依赖配置方式取决于注入器的实现。程序员只需要标注了构造器、方法或字段来说明它们的可注入性（上面的例子就是构造器注入）。依赖注入器通过这些注解来识别一个类的依赖，并在运行时注入这些依赖。此外，注入器要能够在构建时
验证所有的依赖是否满足。相比之下，服务定位器在构建时是不能检测到依赖不满足情况的，直到运行时才能发现。

     注入器实现有很多形式。一个注入器可以通过 XML、注解、DSL（领域规约语言），或是普通 Java 代码来进行配置。注入器实现可以使用反射或代码生成。使用编译时代码生成的注入器甚至可能没有它自己的运行时描述。而其他注入器实现无论在编译时还是运行时可能都不使用代码生成。一个“容器”，其实可以把它定义为一个注入器，不过包 javax.inject 不涉及非常大概念，旨在最小化注入器实现的限制。

@Inject

     可注入的构造器指的是标注了 @Inject 并接受 0 个或多个依赖作为实参的构造器。对于每一个类而言，@Inject 最多只允许对一个类的一个构造器进行标注：

   @Inject

   ConstructorModifiers_opt
SimpleTypeName(FormalParameterList_opt
) Throws_opt
              ConstructorBody

    @Inject 对于仅存在默认构造器（访问修饰符为 public 并且无参数）的情况是可选的，注入器将调用默认构造器：

   @Inject_opt

   Annotations_opt

   public SimpleTypeName() Throws_opt
ConstructorBody

     可注入的字段：

• 被 @Inject 标注。
• 不是 final 的。
• 可以使用任何有效名。

   @Inject FieldModifiers_opt
Type VariableDeclarators;

     可注入的方法：

• 被 @Inject 标注。
• 不是 abstract 的。
• 没有声明类型参数的方法。
• 可以带返回值。
• 可以使用任何有效名。
• 接受 0 个或多个依赖作为实参。

   @Inject MethodModifiers_opt
ResultType Identifier(FormalParameterList_opt
)   

       Throws_opt
MethodBody

     注入器忽略了注入方法的返回值，因为方法的非空返回可能会用于其他上下文（例如 builder-style 的方法链）。

     例子：

   public class Car {

       // Injectable constructor

       @Inject public Car(Engine engine) { ... }

       // Injectable field

       @Inject private Provider<Seat> seatProvider;

       // Injectable package-private method

       @Inject void install(Windshield windshield, Trunk trunk) { ... }

   }

     当一个方法标注了 @Inject 并覆写了其他标注了 @Inject 的方法时，对于每一个实例的每一次注入请求，该方法只会被注入一次。当一个方法没有标注 @Inject 并覆写了其他标注了 @Inject 的方法时，该方法不会被注入。

限定器

   public class Car {

       @Inject private @Leather
Provider<Seat> seatProvider;

       @Inject void install(@Tinted
Windshield windshield,

                            @Big
Trunk trunk) { ... }

   }

     如果一个可注入的方法覆写了其他方法，覆写方法的参数不会自动地从被覆写的方法上继承限定器。

可注入的值

• 是被 @Qualifier、@Retention(RUNTIME) 标注的，通常也被 @Documented 标注。
• 可以拥有属性。
• 可能是公共 API 的一部分，就像依赖类型一样，而不像类型实现那样不作为公共 API 的一部分。
• 如果标注了 @Target 可能会有一些用法限制。本规范只是指定了限定器注解可以被使用在字段和参数上，但一些注入器配置可能使用限定器注解在其他一些地方（例如方法或类）上。

   @java.lang.annotation.Documented

   @java.lang.annotation.Retention(RUNTIME)

   @javax.inject.Qualifier

   public @interface Leather {

       Color color() default Color.TAN;

       public enum Color { RED, BLACK, TAN }

   }

     @Named

Provider<T>

• 可以返回多个实例。
• 实例的返回可以延迟化或可选
• 打破循环依赖。
• 可以在一个已知作用域的实例内查询一个更小作用域内的实例。

   class Car {

       @Inject Car(Provider<Seat> seatProvider) {

           Seat driver = seatProvider.get();

           Seat passenger = seatProvider.get();

           ...

       }

   }

get()

     异常抛出：RuntimeException —— 当注入器在提供实例时遇到错误将抛出此异常。例如，对于一个可注入的成员 T 抛出了一个异常，注入器将包装此异常并将它抛给 get() 的调用者。调用者不应该尝试处理此类异常，因为不同注入器实现的行为不一样，即使是同一个注入器，也会因为配置不同而表现的行为不同。

@Named

     例子：

   public class Car {

       @Inject @Named("driver") Seat driverSeat;

       @Inject @Named("passenger") Seat passengerSeat;

       ...

   }

@Scope

     在下面的例子中，作用域注解 @Singleton 确保我们始终只有一个 Log 实例：

     @Singleton

   class Log {

       void log(String message) { ... }

   }

     当多于一个作用域注解或不被注入器支持的作用域注解被使用在同一个类上时，注入器将生成一个错误。

     一个作用域注解：

• 被标注了 @Scope、@Retention(RUNTIME) 标注的，通常也被 @Documented 标注。
• 不应该含有属性。
• 不应该被 @Inherited 标注，因此作用域与继承实现（正交）无关。
• 如果标注了 @Target 可能会有一些用法限制。本规范只是指定了作用域注解可以被使用在类上，但一些注入器配置可能使用作用域注解在其他一些地方（例如工厂方法返回）上。

     例子：

   @java.lang.annotation.Documented

   @java.lang.annotation.Retention(RUNTIME)

   @javax.inject.Scope

   public @interface RequestScoped {}

     使用 @Scope
来标识一个作用域注解有助于注入器探测程序员使用了作用域注解但却忘了去配置作用域的情况。一个保守的注入器应该生成一个错误而不是去适用该作用域。

     请查阅：

     @Singleton

@Singleton

     请查阅：

     @Scope