Guice辅助注入过度使用替代，依赖注入vs非DI构造函数

Question

我喜欢在构造函数中传递运行时依赖项的主要原因是：

1. 它使依赖关系成为必需的
2. 它提供了设置实例变量的中心位置
3. 将依赖项设置为实例变量，可以避免在类中从一个方法传递到另一个方法，或者将它分两次或多次传递给两个或更多个公共方法

这导致我在使用Guice时使用了很多辅助注射。与不使用DI相比，这会产生额外的代码，因此阅读以下内容：辅助注入到底有多有用？

似乎大多数人不会使用辅助注入在构造函数中传递运行时（派生的，在启动时不可用）依赖项，而是在单个方法中传递它们。这对于上面stackoverflow帖子中给出的简单类来说很好，其中只有一个依赖于依赖项的方法：

public class SomeClass {
    @Inject
    SomeClass(...) {
        ...
    }

    public void doWork(int s) { /* use s */ ... }
}

但是，如果类有许多使用依赖项的方法呢？您是否将其从公共方法传递到私有方法，并要求它传递到所有公共方法？例如：

public class SomeClass {
    @Inject
    SomeClass(...) {
        ...
    }

    public void doWork(int s) { 
     /*some code */
     someOtherMethod(s);
     anotherMethod(s);  

    }
    //any private method that needs it gets it passed in as a param
    private void someOtherMethod(int s)...
    private void anotherMethod(int s)...

    //require it passed in all public methods that need it
    public void anotherPublic(int s){
      someOtherMethod(s);
    }
}

与使用构造函数相反，这增加了一点额外的代码，如下所示：

public class SomeClass {
    private int s;
    SomeClass(int s) {
        this.s = s;
    }

    public void doWork() { 
     someOtherMethod();
     anotherMethod();  

    }
    private void someOtherMethod()...
    private void anotherMethod()...

    public void anotherPublic(){}
}

还是像这样从服务方法设置实例var？

public class SomeClass {
    Integer s;
    @Inject
    SomeClass(...) {
        ...
    }

    public void doWork(Integer s) { 
     /***set instance var this time***/
      this.s = s;
     someOtherMethod();
     anotherMethod();  

    }
    private void someOtherMethod()...
    private void anotherMethod()...

    public void anotherPublicMethod(){
     if(s==null){ //check if s was set already
         throw new IllegalStateException();
      }else{
      /* do something else */
      }
    }


}

还是将依赖项作为参数传递到另一个公共方法中，并在那里设置实例变量？例如：

public class SomeClass {
    @Inject
    SomeClass(...) {
        ...
    }

    public void doWork(Integer s) { 
     /***set instance var this time***/
      this.s = s;
     someOtherMethod();
     anotherMethod();  

    }
    private void someOtherMethod()...
    private void anotherMethod()...

    public void anotherPublicMethod(Integer s){
       this.s = s;
      /* do something else */
    }


}

所以我认为，与使用普通的构造函数相比，将参数从一个方法传递到另一个方法或者抛出非法的状态异常来检查它并不理想，但是显然任何框架/模式都有优点/缺点。

如果我没有以理想的方式分离我的对象，请让我知道你使用的一些准则，即“我只使用每个服务类的一个公共方法，见这本书或关于它的帖子:。”.

在上述情况下，你们会怎么做？

Answer 1

您在问题中明确了使用辅助注入的一些重要原因:它确保了对象实例只存在于完全初始化的状态中，保持了依赖关系，并使对象的公共接口不需要在每个方法中使用可预测的参数。

除了你提到的那些之外，我真的没有任何选择可以添加：

• 为该依赖项添加setter方法，可能需要IllegalStateException检查或良好的默认值
• 使用相同的IllegalStateException检查创建initialize（ints）伪构造函数方法
• 在个别方法中采用参数
• 用自定义工厂替换FactoryModuleBuilder样板，从而创建更多您试图避免的额外样板

我最喜欢的是你似乎在两者之间做出决定——辅助注入或在每种方法中获取参数——主要是因为它们都使对象始终处于可预测的、可用的状态。我在它们之间的决定取决于对象应该携带什么样的状态，该状态是否可变，以及我想如何控制实例。对于Car.licensePlateDigital，车牌号可能会随着汽车实例而变化；每辆车都有一个车牌号，（在本例中）永远不会变化，没有它汽车就无效，所以它应该是一个构造函数参数。相反，存储库

请记住，辅助注入不应该真的需要那么多额外的代码：

/** In module: install(new FactoryModuleBuilder().build(SomeClass.Factory.class)); */
public class SomeClass {
  public interface Factory {
    SomeClass create(int s);
  }

  private final int s;

  @Inject
  SomeClass(/* ..., */ @Assisted int s) {
    this.s = s;
  }

  public void doWork() { /* ... */ }
}