Dagger2 中的静态提供方法答案

【问题标题】：Static provide method in Dagger2Dagger2 中的静态提供方法
【发布时间】：2016-07-28 05:35:32
【问题描述】：

为什么要在提供方法之前使用静态修饰符？

即使我删除了静态修饰符，dagger2 也能正常工作。

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

【问题讨论】：

我不知道。我认为文档实际上是在这种情况下撒谎。您将如何覆盖模拟的静态提供程序方法？你不能。因此，添加static 确实是愚蠢的，并且文档对此毫无意义。尽管它也以其“咖啡示例”而闻名，但实际上并没有告诉您如何使用该库，所以难怪它会做其他没有意义的事情。 /咆哮
对@Provides使用静态函数有助于减少一些生成的代码。

【解决方案1】：

两种风格都可以；是否保持方法静态完全取决于您和您在普通的旧 Java 中的正常“这应该是静态方法”判断。这里，pump 对模块实例没有任何用处，因此该方法很容易成为静态方法。

静态方法调用更快，particularly in Android，因为它们避免了虚拟方法表查找。这也可能使编译器、JIT 运行时或静态分析工具更容易内联。我猜你会通过创建类或方法final来打开类似的优势。

鉴于静态方法不能受制于实例字段，可读性也可能略有提高，但这取决于您。

如果您确信您的 @Provides 方法的行为不会在测试中发生变化，那么您可以利用性能/可读性的提升。但是，如果您需要引用模块状态或希望允许子类/测试覆盖，那么实例方法必然是正确的调用。

【讨论】：

感谢您提供何时使用以及为什么使用的想法。很清楚。我会将此标记为答案。
嗯，他们在 Dagger 文档google.github.io/dagger//testing.html 中使用静态方法进行测试，请参阅底部的@Provides static AuthManager authManager，这是他们的错误，还是我遗漏了什么？
@arekolek 没有错；该模块是 FakeAuthModule，用于测试，但从未更改或覆盖，因为根据“选项 2：单独的组件配置”，它是一个仅用于测试的模块。测试的非最终方法专门启用“选项 1：通过子类化模块覆盖绑定（不要这样做！）”，其标题警告基于该页面上列出的限制。我不反对：除了非常快速或有限的覆盖（或为覆盖而设计的模块）之外，您可能需要一个单独的组件来测试具有单独模块（以及抽象或静态 @Provides 方法）。
谢谢，我想我现在明白了。它们子类化组件并包含不同的模块，但它们本身不子类化模块。