Guiceによる依存性注入:チュートリアルでカバーされていないもの
-
10-07-2019 - |
質問
私は Google Guice を使用して依存性注入を行い、統合を開始しました私の既存のアプリケーション。ここまでは順調ですね。依存関係の他に、文字列、データソースなどを必要とする多くのクラスがあります。 NamedBindingsがあることは知っていますが、各クラスのコンストラクターに渡す必要のある単純な文字列ごとに注釈を作成したくありません。次に、AssistedInjectと呼ばれるものがあり、私のためにFactory実装を作成します。うわー、しかし、私はまだ工場のインターフェースを定義する必要があります。依存関係があるクラスの場合は問題ありませんが、このサンプルクラスについてはどうですか:
public class FooBarClass {
public FooBarClass(String name, String anotherOne) {
// Some stuff
}
}
Guiceまたはより一般的にはDIを正しい方法で使用する方法に疑問がある場合があります。 <!> quot;よく耳にします:XYZ Frameworkは新しい new です。<!> quot;しかし、これは、DIフレームワークですべてインスタンスを作成する必要があることを暗黙的に示しています。
必要なインスタンスは1つだけです
このクラスのインスタンスが1つだけ必要な場合はどうなりますか?このクラスには、2つの文字列以外に絶対に依存関係はありません。 1回だけインスタンス化され、シャットダウンフックとしてJVMに渡されるシャットダウンフックについて考えます。 Guiceでこのインスタンスを作成する必要がありますか?注入するものが何もないため、これは非常に馬鹿げているように見えますが、両方のパラメーターをガイドに渡すためにファクトリーインターフェイスを作成し、DIを使用するためにFooBarClassのインターフェイスを作成する必要があります。
複数のインスタンスが必要です
同じことが、このクラスの複数のインスタンスが必要な場合にも当てはまります。依存関係はありませんが、ボイラープレートコードの束を作成して、何も取得しないといけません。これは間違っているようです。
では、DIやGuiceをどのように使用するのですか?
どうもありがとう!
解決
データから依存関係を分割すると役立つ場合があります。
- 多くの場合、依存関係はサービスです:データベース、クロック、RPCスタブ。さらに、これらに階層化されたすべてのアプリケーションコード:
UserAuthenticator
、PaymentHandler
、およびEmailGateway
。 - データは、
Date
、Map<String,InetAddress>
、またはCustomer
でもあります。これらは、シンプルなメモリ内ドメインオブジェクトです。
DIは当然、物事の依存関係の側面に最適です。データモデルクラスには引き続きnew
を使用する必要があります。
他のヒント
個々の顧客などの複数のインスタンスを作成している場合、それらをインジェクトすることは意味がありません。意味をなすのは、すべての依存関係を持つCustomerインスタンスを作成できる@SingletonスコープであるCustomerFactoryを作成することです。
特定のクラスをテストするときに複雑さを無視(分離)する場合は、依存関係を挿入します。クラスが単なるデータホルダーである場合、そのコードは簡単です(get、set、equals)。ターゲットクラスをテストするときにモックを作成する必要はありません。そのため、データインスタンスの注入はやり過ぎです(通常は困難です)。コードが簡単でない場合、クラスはデータホルダー以上のものであるため、ユニットテストでコードを挿入およびモックする必要があります。