8

Google Guice for Dependency Injectionをいじって、既存のアプリケーションに統合し始めました。ここまでは順調ですね。依存関係に加えて、文字列、データソースなどを必要とする多くのクラスがあります。NamedBindingsがあることは知っていますが、クラスごとにコンストラクターに渡さなければならない単純な文字列ごとにアノテーションを作成したくはありません。次に、AssistedInjectと呼ばれるものがあり、ファクトリの実装を作成してくれます。うわー、しかし私はまだ工場のインターフェースを定義する必要があります。依存関係があるクラスでは問題ありませんが、このサンプルクラスについてはどうでしょうか。

public class FooBarClass {
    public FooBarClass(String name, String anotherOne) {
        // Some stuff
    }
}

Guiceの使い方、より一般的にはDIの正しい使い方がわからない場合があります。「よく耳にしますが、XYZフレームワークは新しいものです。」しかし、これは暗黙のうちに、DIフレームワークを使用してすべてのインスタンスを作成する必要があることを意味します。

必要なインスタンスは1つだけです

このクラスのインスタンスが1つだけ必要な場合はどうなりますか？このクラスには、2つの文字列以外に依存関係はまったくありません。一度だけインスタンス化され、シャットダウンフックとしてJVMに渡されるシャットダウンフックについて考えてみてください。Guiceでこのインスタンスを作成する必要がありますか？注入するものがないため、これは非常に馬鹿げているように見えますが、Guideの両方のパラメーターを渡すためのファクトリインターフェイスを作成し、FooBarClassがDIを使用するためのインターフェイスを作成する必要があります。

複数のインスタンスが必要です

このクラスの複数のインスタンスが必要な場合にも同じことが当てはまります。依存関係はありませんが、何も得られないようにボイラープレートコードをたくさん作成する必要があります。これは私には間違っているようです。

では、DIやGuiceをどのように使用することになっていますか？

どうもありがとう！

4

3 に答える 3

23

データから依存関係を分割すると役立つ場合があります。

  • 多くの場合、依存関係はサービスです。データベース、クロック、RPCスタブです。さらに、、、、およびのすべてのアプリケーションコードがこれらに階層化されていUserAuthenticatorます。PaymentHandlerEmailGateway
  • データはまさにそれです：Date、、Map<String,InetAddress>またはCustomer。これらは、単純なメモリ内ドメインオブジェクトです。

DIは当然、物事の依存関係の側面に最も適しています。newデータモデルクラスには引き続き使用する必要があります。

于 2009-06-25T00:35:59.273 に答える
2

特定のクラスをテストするときにその複雑さを無視（分離）する場合は、依存関係を挿入します。クラスが単なるデータホルダーである場合、そのコードは簡単です（get、set、equals）。ターゲットクラスをテストするときにそれをモックする必要はないので、データインスタンスを注入するのはやり過ぎです（そして通常は難しいです）。コードが簡単でない場合、クラスはデータホルダー以上のものであり、単体テストでそれを挿入してモックする必要があります。

于 2009-07-14T13:29:18.160 に答える
2

個々の顧客などの複数のインスタンスを作成している場合、それらを挿入することは意味がありません。理にかなっているのは、すべての依存関係を持つCustomerインスタンスを作成できる@SingletonスコープであるCustomerFactoryを作成することです。

于 2009-07-09T07:15:28.373 に答える