それらはほぼ同じです。この@Singleton
構文は@Provides
、メソッドに注釈を付けたり、クラス自体に注釈を付けたりするのに役立ちます(ただし、スコープの注釈はモジュール内に保持することをお勧めします)。
違いは、キーがシングルトンとマークされていることです。これは、vs @Singleton
(Singleton.class
またはScopes.SINGLETON
、、クラスアノテーション、または暗黙のシングルトン)とは関係がなく、デフォルトの構文で簡単にできることと関係があります。例えば:asEagerSingleton
@Singleton
toInstance
public class MyModule extends AbstractModule {
@Override public void configure() {
bind(A.class).to(AImpl.class).in(Singleton.class);
bind(B.class).to(BImpl.class);
bind(BImpl.class).in(Singleton.class);
}
@Provides @Singleton C provideC() { return new CImpl(); }
@Provides @Singleton D provideD(DImpl dImpl) { return dImpl; }
@Provides E provideE(EImpl eImpl) { return eImpl; }
@Provides @Singleton EImpl provideEImpl() { return new EImpl(); }
}
上記では、インターフェイスをクラスにバインドし、インターフェイスをクラスにバインドA
しましたが、動作は異なります。AImpl
B
BImpl
- 注入すると、毎回
A
同じインスタンスが取得されます。AImpl
- インジェクトは毎回
AImpl
異なるものを取得しますが、そのすべてがのインスタンスとは異なります。AImpl
A
- 注入すると、毎回
B
同じインスタンスが取得されます。BImpl
- インジェクトは、インジェクトしたのと同じインスタンス
BImpl
も取得します。BImpl
B
ご覧のとおり、各キーは異なり、インターフェイスのみがシングルトンにバインドされている場合、Guiceは複数の実装インスタンスを許可します。A
インジェクトとインターフェースのみをB
使用する場合、動作は同じように見えますが、同じインジェクターからインターフェースと実装の両方を注入すると、動作が異なる場合があります。
同様のロジックが@Provides
メソッドにも当てはまります。
- 注入
C
すると、常に同じCImpl
インスタンスが返されます。
- 注入可能なパブリックゼロ引数コンストラクターがない場合を除いて、注入は毎回
CImpl
新しいものを作成します。そうすると、注入は失敗します。CImpl
CImpl
- 注入
D
すると、常に同じDImpl
インスタンスが返されます。
- インジェクト
DImpl
は毎回新しいインスタンスを返し、それぞれがによって返されるインスタンスとは異なりD
ます。
- 注入すると、毎回
E
同じインスタンスが返されます。EImpl
- インジェクトは、同じインスタンスがインジェクト
EImpl
することも取得しますE
。
これにより、ある程度の柔軟性が得られます。Cache
ある数の最近取得されたオブジェクトを保持し@User Cache
、@Product Cache
両方を注入可能にするという仮説を想像してみてください。の場合、オブジェクト間(およびベアインジェクション)でbind(Cache.class).in(Singleton.class)
1つのキャッシュが共有されますが、その場合、注釈付きキーはシングルトンスコープに保持され、各オブジェクトタイプには独自のキャッシュがあります。Cache
bind(Cache.class).annotatedWith(User.class).to(Cache.class).in(Singleton.class)