Guice @Provides方法与提供程序类

我正在做一个很大的项目,有很多注入。当前,我们正在使用一个类,该类Provider为需要一次的每次注入实现,并且它们大多具有一个行get方法。

每当我需要一个新的提供程序时,创建一个新的类就变得很烦人。使用提供程序类比使用@Provides方法有什么好处,Module反之亦然?

回答:

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

/**

* Class-style provider.

* In module: bind(Foo.class).annotatedWith(Quux.class).toProvider(MyProvider.class);

*/

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");

}

}

/**

* Method-style provider. configure() can be empty, but doesn't have to be.

*/

class MyModule extends AbstractModule {

/** Name doesn't matter. Dep is injected automatically. */

@Provides @Quux public Foo createFoo(Dep dep) {

return dep.provisionFoo("bar", "baz");

}

@Override public void configure() { /* nothing needed in here */ }

}

无论哪种样式,即使键绑定到类或实例,Guice都可以让您注入FooProvider<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。除非有您自己的实际逻辑,否则无需创建显式提供程序。

以上是 Guice @Provides方法与提供程序类 的全部内容, 来源链接: utcz.com/qa/409274.html

回到顶部