这是一个Guice反模式吗？

public class Widget { 
    @Inject 
    Fizz fizz; 

    public Widget(Fizz fizz) { 
     super(); 

     setFizz(fizz); 
    } 

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

这是一个Guice反模式？！？！这是一个Guice反模式吗？

如果我说“fizz将被注入（通过@Inject）”，但然后我允许构造函数和设置器接受一个嘶嘶声，这是不必要的多余？它会引起与Guice喷油器的冲突吗？

我想我很困惑，：

何时应标注属性与@Inject，与
时候你应该通过构造函数/吸气自己“注入”属性

有什么想法？提前致谢！

来源

2012-04-07 IAmYourFaja

不知道为什么会发生冲突（我只是不知道），但似乎没有理由明确禁止在Guice之外设置自己的Fizz，除非这是一个特定的目标。 – 2012-04-07 18:42:25

为什么不使用这样的东西（即使用构造函数注入）？

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-07 18:42:40 mglauche

有什么区别？如果我注释属性，而不是构造函数，Guice如何表现不同？ – IAmYourFaja 2012-04-07 18:44:35

当类需要多个依赖项时，注释构造函数一次就可以避免注释每个字段。 – 2012-04-07 18:46:50

区别在于变量可用的时间。如果你做构造函数注入，你显然可以在构造函数中使用它们，如果你使用getter/setter注入，注入的成员只有在构造函数完成后才可用。 – mglauche 2012-04-07 18:46:56

见我肯定会说这是一个问题，而不是因为吉斯不能做到这一点，但因为你的代码有缺陷。 Guice将尝试调用默认的无参数构造函数（不存在）并失败。

但即使您添加了无参数构造函数，这仍然是一种反模式。我已经使用了DI框架一段时间，从未遇到过需要进行现场注入的情况。我确信这有一个用例，否则Guice人不会包含它，但是如果没有特殊的代码，无论是字节码操作还是反射，都无法测试代码。

建设者注入通常是最好的，原因有很多。它使任何调用者都清楚地知道你的依赖关系是什么，它允许你同时初始化所有类的不变量（避免一个部分初始化的类），它是唯一允许你创建不可变对象的DI风格，它是线程安全并降低程序复杂性。

我只用于方法注入的用例是当我不想要一个子类来声明父类的依赖关系，或者当我想要一个“可选”依赖项时，但这些很少见。

来源

2012-04-08 14:36:21

您应该使用构造函数注入对于那些REQUIRED依赖。使用属性注入当依赖项是可选。

来源

2012-04-08 16:37:15 Rookian

这是一个Guice反模式吗？

回答

相关问题