android - 提供方法依赖

Question

在文档中它说 @Provides 方法可能有自己的依赖关系，例如：

@Provides Pump providePump(Thermosiphon pump) {
  return pump;
}

如果我这样写会发生什么变化：

@Provides Pump providePump() {
  return new Thermosiphon();
}

在第一个片段中：该方法的泵从何而来？

Answer 1

该文档还显示了Thermosiphon该类：

class Thermosiphon implements Pump {
  private final Heater heater;

  @Inject
  Thermosiphon(Heater heater) {
    this.heater = heater;
  }

  ...
}

此类的构造函数用 注释@Inject。这让 Dagger 知道在需要 a 时使用此构造函数Thermosiphon，并自动为其提供一个Heater实例，因此您不必这样做。

你自己创建一个新Thermospihon实例是完全没问题的，但是 Dagger 这样做可以省去你的麻烦。例如，Heater如果您手动进行，则需要从某处获取一些参考。这就是 Dagger 的全部意义所在，因此您不必进行繁琐的重复工作。

Answer 2

如果每次请求实例时都创建一个新的 Thermosiphon.class 实例，那么这些实际上是相同的。如果它是一个单例（或以任何方式限定），那么我们就有区别。

如果您有以下内容，那么第一个示例是单例的别名。但是，第二个示例仍将每次都创建新实例。

@Provides
@Singleton
Thermosiphon provideThermosiphon() {
  return new Thermosiphon();
}

就个人而言，我更喜欢第一种方法。使用第一种方法，您可以稍后添加或更改提供程序，并在将实例传递给别名之前调整实例的范围或状态。它似乎更灵活一些。

Answer 3

它查找在您的模块中声明的其他 bean

例如：

@Module
public class MainModule {


    @Provides
    public EmailServiceApiGateway provideEmailServiceApiGateway() {
        return new EmailServiceApiGateway();
    }

    @Provides
    public EmailSendingActivityPresenter provideEmailSendingActivityPresenter(EmailServiceApiGateway emailServiceApiGateway) {
        return new EmailSendingActivityPresenterImpl(emailServiceApiGateway);
    }
}

因此，在上述情况下，EmailServiceApiGateway 会自动注入到 EmailSendingActivityPresenter。