java - 绑定(bind)到 TypeLiteral 是 google guice 中的好习惯还是坏习惯

Question

Google guice 使用 new TypeLiteral<C<T>>() {}克服我们不能使用 C<T>.class 的事实.

现在常见的有:

bind(new TypeLiteral<C<T>>() {}).to(MyCSubclassTypedToT.class);

然而，想象一个不同的场景。我们有一个通用接口(interface)，我们想要注入(inject)它，我们拥有的实现由一个通用类提供。

Guice 允许您这样做:

bind(new TypeLiteral<MyGenericInterface<T>>() {}).to(new TypeLiteral<MyGenericClass<T>>() {});

另一种方法是像这样扩展 MyGenericClass:

MyTypedClass extends MyGenericClass<T>

然后像这样绑定(bind)它:

bind(MyGenericInterface<T>>() {}).to(MyTypedClass.class);

如果 MyGenericInterface 被注入(inject)很多(尽管类型不同)，并且每次注入(inject)它时我都使用 MyGenericClass，后一种方法会导致代码过于冗长。因此我倾向于使用前者。

我非常想听听其他人对在 guice 绑定(bind)的 to 子句中使用 TypeLiteral 的意见。恐怕我可能有点做空，因此看不到这种方法的缺陷。

Answer 1

在这种情况下，使用 TypeLiteral 作为通用实现让我觉得要好得多。

让我这样表述:“如果您不使用 Guice，子类 MyTypedClass 会存在吗？”。 Guice 的一个基本准则是:您不必更改您的实现类以适应 DI 框架(好吧，@Inject 注释之类的东西除外)。

您从具体但通用的类的子类化中得到什么？一大损失是您必须在所有子类中复制 MyGenericClass 的构造函数。总而言之，这似乎是没有太多收获的额外代码。

总而言之，使用TypeLiteral 通常没有任何问题。如果它在绑定(bind)子句的 .to(...) 部分(与 bind(...) 相对)，它甚至不会影响公开- Module 绑定(bind)的可见部分，所以我认为没有什么可担心的。