Guice @Provides方法与提供程序类

Guice @Provides方法与提供程序类

据我所知，它们在大多数简单情况下是完全等效的。

class MyProvider implements Provider<Foo> {  @Inject Dep dep;  // All sorts of injection work, including constructor injection.  @Override public Foo get() {    return dep.provisionFoo("bar", "baz");  }}class MyModule extends AbstractModule {    @Provides @Quux public Foo createFoo(Dep dep) {    return dep.provisionFoo("bar", "baz");  }  @Override public void configure() {  }}

无论哪种样式，即使键绑定到类或实例，Guice都可以让您注入

Foo

和

Provider<Foo>

。

get

如果直接获取实例，Guice会自动调用，如果

Provider<Foo>

不存在则创建一个隐式实例。绑定注释在两种样式中均有效。

@Provides的主要优点是紧凑性，特别是与匿名内部Provider实现相比。但是请注意，在某些情况下，您可能希望使用Provider类：

• 您可以创建自己的长期Provider实例（可能带有构造函数参数），并将键绑定到这些实例而不是类文字。

  bind(Foo.class).toProvider(new FooProvisioner("bar", "baz"));

• 如果您使用的是与JSR 330（javax.inject）兼容的框架，则可以轻松绑定到javax.inject.Provider类或实例。com.google.inject.Provider扩展了该接口。

  bind(Foo.class).toProvider(SomeProviderThatDoesntKnowaboutGuice.class);

• 您的提供者可能很复杂，无法纳入自己的类。根据您的测试结构，以这种方式测试提供程序可能会更容易。

• 提供程序可以扩展抽象类。使用@Provides方法执行此 *** 作可能并不容易或直观。

• 您可以将多个密钥直接绑定到同一个提供程序。每个@Provides方法仅产生一个绑定，尽管您可以将其他键绑定到该 键 （此处为@Quux Foo），然后让Guice进行第二次查找。

• 如果您想要（例如）在不使用Guice范围或绑定的情况下缓存或记忆实例，则提供程序很容易装饰或包装。

  bind(Foo.class).toProvider(new Cache(new FooProvisioner("bar", "baz")));

---

重要提示
：尽管这对于Guice无法创建的类来说是一个不错的策略，但是请记住，Guice可以自动

Provider<T>

为您创建的T并

bind

以任何方式（包括类名，键或实例）插入A。除非有您自己的实际逻辑，否则无需创建显式提供程序。