java - 在非集合中使用泛型

Question

今天看到几个类似的问题-让我想到:

什么时候使用泛型的规则是什么？

什么时候涉及集合？

什么时候有返回集合元素的 getter 方法？

对象在其生命周期内是否改变了类型？

关系是否是类的组合/聚合？

对于您应该问自己以确定是否应该使用泛型的问题，似乎没有达成共识。这纯粹是一个自以为是的决定吗？

更容易问什么时候不应该使用泛型？？

Answer 1

在我回到项目符号列表的第一点之前，让我从一些关于泛型和类型信息的一般观点开始。

泛型可防止不必要的类型转换。

你还记得泛型出现之前的 Java 吗？类型转换无处不在。

这就是类型转换的本质:你告诉编译器一个对象的类型，因为编译器不知道或不能推断它。

类型转换的问题在于您有时会犯错误。您可以向编译器建议类 Fiddle 的实例。是 Frobble ( (Frobble)fiddle )，编译器会很高兴地相信你并编译你的源代码。但是如果事实证明你错了，你会在很久以后得到一个很好的运行时错误。

泛型是一种不同的、通常更安全的让编译器保留类型信息的方式。基本上，编译器比人类程序员更不可能犯打字错误... 需要的类型转换越少，潜在的错误源就越少 !一旦确定列表只能包含 Fiddle对象( List<Fiddle> )，编译器将保留此信息并防止您必须将该列表中的每个项目类型转换为某种类型。 (您仍然可以将列表项转换为 Frobble ，但是为什么要这样，既然编译器让您知道该项目是 Fiddle !？)

我发现 泛型大大减少了类型转换的需要 ，所以大量类型转换的存在——尤其是当你总是转换为相同的类型时——可能表明应该使用泛型来代替。

让编译器保留尽可能多的类型信息是一件好事，因为 可以更早地发现打字错误 (在编译时而不是在运行时)。

泛型替代“泛型”java.lang.Object类型:

在使用泛型之前，如果您想编写一个适用于任何类型的方法，您可以使用 java.lang.Object父类(super class)型，因为每个类都从它派生而来。

泛型还允许您编写适用于任何类型的方法，但不会强制您或编译器丢弃已知类型信息——这正是将对象强制转换为 Object 时发生的情况。类型。所以，频繁使用Object类型可能是泛型可能适用的另一个指标。

When a collection is involved?

为什么泛型看起来特别适合集合？因为，根据上述推理，很少允许集合仅包含任何类型的对象。如果是这样，那么 Object type 是合适的，因为它不会对集合施加任何限制。但是，通常您希望集合中的所有项目(至少)都是 Frobble (或其他类型)，如果您让编译器知道它会有所帮助。泛型是如何做到这一点的方式。

Whether the relationship is composition/aggregation to the class?

您已链接到 another question询问 class Person有一个 car属性应设为通用的 class Person<T extends ICar> .

在这种情况下，这取决于您的程序是否需要区分本田人和欧宝人。通过制作这样的 Person类泛型，你本质上介绍了不同种类的人的可能性。如果这确实解决了您代码中的问题，那就去做吧。但是，如果它只会带来障碍和困难，那么请抵制这种冲动并继续使用您的非通用 Person类(class)。

侧节点:请记住，您不必使整个类通用；您只能使一些特定的方法通用。至少在 .NET 生态系统中，建议尽可能将泛型保持为“本地”，即当仅使方法成为泛型就足够时，不要将类变成泛型。