并与Java中的构造函数注入进行了比较

我见过几个倾向于使用方法注入的框架，例如：

public abstract class MyClass {
    /** Create the class here */
    protected abstract Prototype createPrototype();

    public void doSomething() {
        createPrototype().foo();
    }
    public void doSomethingElse() {
        createPrototype().bar();
    }
}

他们可能会使用匿名内部类来添加自定义功能/创建您的首选对象：

   new MyClass() {
      createPrototype() {
        return prototype;
      }
   }

还有其他支持构造函数注入的，比如guice

---

与构造函数注入相比是否有优势，使用方法注入是否是一种良好的实践

在一些罕见的情况下，基于构造函数的依赖项注入是不可能的，但是我认为通常认为使用基于构造函数的DI比使用基于方法的DI更好，因为这样你的对象就可以在一切就绪的情况下初始化，如果缺少了什么，那么您可以在对象构造中一次抓住它。另外，您通常不希望在设置依赖项之后弄乱它们，因此为它们添加一堆setter在某种程度上破坏了封装。如果你从来都不想使用setter，那么拥有setter有什么意义呢？

现在还不清楚你在问什么。您的第一个示例不是方法注入，您也没有提供任何上下文（有时一个或另一个显然更好，而且越来越多的字段直接通过反射设置）。我认为构造函数注入和字段注入是一个更有趣的问题，因为它们在用例中的差异更大。第一个示例来自方法注入的spring示例。使用方法注入没有重大问题或危害？@BerlinBrown再次阅读了这个问题，我发现您指的是spring的查找方法注入spring使用字节码生成来创建一个工厂方法，该方法返回原型范围的bean，以便您可以在单例范围的bean中使用它。我对竞争对手（guice等）了解不够，无法进行比较。我不确定将它与构造函数注入相比较是否有意义。我不一定是在谈论spring的查找。我只是举了他们的例子。我对使用这种方法更感好奇。你提供了很好的信息。@BerlinBrown好的。我认为关键的是，在这个例子中，使用了这个技术，因为如果不是这样的话；不可能有一个在其中使用原型范围bean的单例bean。如果有一个面向构造函数的替代方案来解决sam问题，那么我不知道。干杯：）