作者归档：考拉哥

原文地址：https://code.google.com/p/google-guice/wiki/InjectingProviders InjectingProviders（注入的提供者）：通过注入提供者来产生对象支持依赖注入。 和普通的依赖注入一样，每一种类型都能够确切地获取它所依赖的实例。RealBillingService包含CreditCardProcessor和TransactionLog，当灵活性是必须地时，Guice会绑定一个提供者，当调用get()方法时，提供者会产生一个对象的值。 这个提供者的类型是通过泛型参数来区分的，在Provider和Provider之间。只要是注入值的地方都可以通过注入提供者来代替。 对每一种绑定或者是注解，注入器都有内建绑定的相应的提供者。 Providers for multiple instances（不同实例的提供者）：顾名思义。 在使用提供者的过程中，你可能需要一种类型的不同实例。设想当一个披萨支付失败时，你的应用程序正在保存一个概括条目和一个详细订单。用各种提供者，你就能随时获取一个新的条目： Providers for lazy loading(延时加载的提供者)：在提供者里做部分逻辑延迟产生大对象。 当你在获取关于一个类型的依赖，同时这个依赖的创建开销又特别的大时，你能够用提供者来推迟这项工作。当你不是非常需要这个依赖时，这是很有用的： Providers for Mixing Scopes(混合作用域的提供者)：提供者产生不同作用域的对象。 依赖一个很窄的作用域的对象是一个错误，设想你使用了单例的事务日志，但是这个事务日志对当前用户需要用的是请求作用域。如果你直接注入用户就会出错，因为用户是随着请求的改变而改变的。自从提供者能够按需的产生对象值，它们使你安全的混合多个作用域成为可能：

原文地址：https://code.google.com/p/google-guice/wiki/Injections Injections（各种注入）：常见的有构造函数注入，set方法注入，成员变量注入，前面几篇提到过，就说说没有提到的。 Optional Injections（可选择的注入）：就是在注入时可以选择使用注入，通过@Inject(optional=true)实现。 或者是在成员变量上： On-demand Injection(按需注入)：方法注入或者变量注入可能用在初始化一个已经存在的实例。你可以用Injector.injectMembers API: Static Injections(静态注入)：不推荐，依赖关系不透明和受类的全局状态影响。 Automatic Injection（自动注入）：自动注入 Guice自动注入有如下情况： 在绑定代码中，实例被传递到toInstance() 在绑定代码中，provider实例被传递到toProvider()

原文地址：https://code.google.com/p/google-guice/wiki/Scopes Scopes：作用域。 默认情况下，Guice每次在调用时都会返回一个新的实例，这种行为是可以通过作用域配置的，作用域允许复用对象实例。在一个应用服务的生命周期中，对象可能是单例的（@Singleton）,也可能是一个回话的（@SessionScoped），也可能是一个请求的（@RequestScoped）。Guice在web应用中也包含一个servlet扩展的作用域。自定义作用域可以在不同类型的应用中使用。 Applying Scopes 作用域使用有不用的方式，例如注解， 也可以配置在代码里， 也可以注解在@Provides方法处， 如果有些冲突的作用域同时在一个类型上或者代码里的bind()方法上配置，那么bind()的配置生效。如果一个类型你不想给它设置要作用域，那么就绑定Scopes.NO_SCOPE。 像链接绑定那样，作用域应用于绑定的父类型，而不是绑定目标实现类。设想我们有一个同时实现Bar接口和Grill接口的实现类Applebees，这就要求需要同时绑定的这两种类型，一种是类型Bar，另一种是Grill： 这是因为作用域应用于这个绑定的类型（Bar，Grill），而不是满足这个类型的实现类Applebees，为了允许只有一个实例，用一个注解@Singleton声明在父类型上，或者在代码里绑定。 这种绑定使得以上的其他两种.in(Singleton.class)语句不必要。这种in()语句还接受像RequestScoped.class或者是ServletScopes.REQUEST的注解： 这种注解是推荐优先的，因为它允许这个模块在不同的类型应用中复用，打个比方，一个被@RequestScoped注解的对象即能够在web应用的http请求中被使用，也可以在一个API服务器的rpc中被使用。 Eager Singletons Eager Singletons（各种饥渴的单例）：不是延迟的，是饿汉式的单例。 Guice有特殊的语法定义把单例为饿汉式的： Guice有特殊的语法定义把单例为饥渴的： 饿汉式的单例可以很快揭示初始化问题，并确保最终用户获得一致的，直观的体验。懒汉式的单例保证了一个快速的编辑-完成-启动的开发周期，用这个Stage的枚举可以区分那种策略被使用： PRODUCTION DEVELOPMENT .asEagerSingleton() eager eager .in(Singleton.class) eager lazy .in(Scopes.SINGLETON) eager lazy @Singleton eager* lazy Guice会在已知类型的情况下创建饿汉式单例，这些类型都是在自己的模块，并加上这些类型递归依赖提到的类型。