Guice 的@ImplementedBy 是邪恶的吗？在某些情况下合适吗？

Question

我听说过“@ImplementedBy 是邪恶的”的说法，理由是它破坏了 DI 概念并使接口了解其实现者。

这在某些情况下可能是正确的，但我经常发现它只会带来更简洁的代码（无需维护模块），而不会真正损害过程中的任何东西。

作为实用主义者而非纯粹主义者，您认为什么时候值得使用@ImplementedBy？

Answer 1

我对@ImplementedBy 有同样的呃、恶心、恶心的感觉，但同时它非常有用。 Spring 必须扫描你给它的包列表中的所有类。在 Guice 中，您不必配置要扫描的包列表，@ImplementedBy 是关键（如果不使用 Binder 来绑定）。当它在第一个 Injector.getInstance 上进入您的对象层次结构并命中一个接口时，它然后使用 @ImplementedBy 来查找默认实现（只要 Binder 中没有任何内容覆盖该默认值）。

我们也使用@ImplementedBy。我们发现它使用起来非常好，有点糟糕，但它工作得很好，而且因为它是 DI，它并不真正依赖于实现，因为无论如何你都可以用新的绑定覆盖。

同时接口在 DI 框架中的使用通常越来越少。我们项目中的所有 DAO 接口都消失了，我们仍然可以为 DAO 交换模拟对象。 java 类是隐式接口，可以在不需要接口的情况下进行模拟。我们现在保留主要 api 的接口使用非常清晰，而不是与实现代码混淆。对于 DAO，我们不再需要这个了。

Answer 2

您通常应该更喜欢显式绑定而不是即时 (JIT) 绑定。显式绑定允许注入器在注入器创建时抓取依赖图。如果依赖项丢失或无效，这允许 Guice 快速失败。使用像 @ImplementedBy 这样的即时绑定，Guice 在绑定执行之前无法报告问题。

JIT 绑定与 PrivateModules/子注入器的交互也很差。虽然大多数应用程序不需要这些功能，但如果每个绑定都属于特定模块，那么当您这样做时，痛苦会减轻。

Answer 3

当一个接口不打算有多个实现但必须成为依赖注入过程的一部分时，它很有用，因为它具有必须由框架注入的依赖项。

Answer 4

我可以理解为什么 Google 会这样做，但有一个首选的实现并不一定是邪恶的。请注意，文档说它是针对 default 实现的，而不是 only 一个。

顺便说一句，我发现这个问题是因为我在互联网上搜索@ImplementedBy 概念的现有实现。

我创建了一个名为 @ImplementedBy 的注解来放置在我的一个接口上。当使用纯的、未注入的反射时，这是告诉接口使用什么实现的最简单方法，尤其是在使用仅理解接口的现有 API 时。 （接口，不是实现）

注释允许我用一行注释和装饰器内的一行来泛化一些非常粗糙的生成器。这么简单的操作我不用依赖框架。

Answer 5

对我来说，是的，如果您将其用于硬线绑定并且永远不会重用绑定，因为您颠倒了接口的含义，这是邪恶的。我同意@thSoft，这是一个很常见的模式，但我什至不清楚，为什么我们没有@Implements 注释。 此外，给定的默认实现不是运行时使用的也可能令人恼火。

只是为了弄清楚google sayed to that是什么

Annotate types tell the injector what their default implementation type is. …

！！它还消除了诸如

之类的通用接口

@ImplementedBy(MyImpl.class)
public interface MyInterface<SIn,SOut> {}

public class MyImpl implements MyInterface<String, Integer> {}

通常不会只实施一次。 详情请见Inject Generic Implementation using Guice。