绑定到 TypeLiteral 在 google guice 中是好是坏

Question

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

现在常见于以下情况：

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

然而，想象一个不同的场景。我们有一个泛型接口，我们想要注入它，我们拥有的实现由一个泛型类提供。

Guice 允许您这样做：

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

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

MyTypedClass extends MyGenericClass<T>

然后像这样绑定它：

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

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

我很想听听其他人对在 guice 绑定的 to 子句中使用 TypeLiteral 的意见。恐怕我的选址有点短，因此看不到这种方法的缺陷。

Answer 1

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

让我这样说：“如果你不使用 Guice，子类 MyTypedClass 会存在吗？”。 Guice 的一个基本准则是：你不应该改变你的实现类来适应 DI 框架（嗯，除了 @Inject 注释之类的东西）。

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

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

Answer 2

通常有两种情况：

1. 您想将MyGenericInterface 的所有实现绑定到MyGenericClass
2. 您想根据类型绑定MyGenericInterface 的实现

对于第一种情况，bind(MyGenericInterface).to(MyGenericClass); 就足够了，更简单，更容易理解。

对于第二种情况，您需要将特定类的实现绑定到特定实现，TypeLiteral 将发挥作用。

此外，您问题中的代码不清楚T 是实际类还是泛型类型。如果是泛型类型，

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

和

MyTypedClass extends MyGenericClass<T>

不会编译，因为没有提供一些实际的类。