0 
public class Widget {
    @Inject
    Fizz fizz;

    public Widget(Fizz fizz) {
        super();

        setFizz(fizz);
    }

    public void setFizz(Fizz fizz) {
        this.fizz = fizz;
    }
}

これはGuiceのアンチパターンですか？！？！

fizz「 （経由で）注入されます」と言っても@Inject、コンストラクターとセッターがフィズを受け入れることを許可した場合、これは不必要に冗長ですか？Guiceのインジェクターとの競合を引き起こす可能性がありますか？

私は次のことについて混乱していると思います：

  • @Injectプロパティに、vsで注釈を付ける必要がある場合。
  • コンストラクター/ゲッターを介して自分でプロパティを「注入」する必要がある場合

何かご意見は？前もって感謝します！

4

3 に答える 3

4

このようなものを使用しないのはなぜですか（つまり、コンストラクターインジェクションを使用します）？

public class Widget {
    private Fizz fizz;

    @Inject
    public Widget(Fizz fizz) {
        super();

        this.fizz = fizz;
    }

}

http://code.google.com/p/google-guice/wiki/Injectionsも参照してください

于 2012-04-07T18:42:40.533 に答える
3

REQUIREDである依存関係には、コンストラクター インジェクションを使用する必要があります。依存関係がOPTIONALの場合は、プロパティ インジェクションを使用します。

于 2012-04-08T16:37:15.857 に答える
1

これは間違いなく問題だと思います。Guice ができないからではなく、コードにバグがあるからです。Guice はデフォルトの引数のないコンストラクター (存在しない) を呼び出そうとしますが、失敗します。

しかし、引数なしのコンストラクターを追加したとしても、これは依然としてアンチパターンです。私はしばらくの間 DI フレームワークを使用してきましたが、フィールド インジェクションを行う必要に遭遇したことはありません。ユースケースがあると確信しています。そうでなければ、Guice の人たちはそれを含めなかったでしょうが、バイトコード操作またはリフレクションのいずれかの特別なコードなしでは、コードをテストすることが不可能になります。

コンストラクター注入は、多くの理由で一般的に最適です。依存関係が正確に何であるかを呼び出し元に明確にし、クラスのすべての不変条件を同時に初期化できるようにし (部分的に初期化されたクラスを回避)、不変オブジェクトを作成できる唯一の DI フレーバーです。スレッドセーフで、プログラムの複雑さを軽減します。

私がメソッド インジェクションを使用するのは、サブクラスで親の依存関係を宣言する必要がない場合、または「オプションの」依存関係が必要な場合だけですが、これらはまれです。

于 2012-04-08T14:36:21.113 に答える