第5章 泛型

第23条：请不要在新代码中使用原生态类型

声明中具有一个或者多个类型参数的类或者接口，就是泛型类或者接口。

每种泛型定义一组参数化的类型，构成格式为：先是类或是接口的名称，接着用尖括号(<>)把对应于泛型形式类型参数的实际类型参数列表括起来。

最后一点，每个泛型都定义一个原生态类型(raw type)，即不带任何实际类型参数的泛型名称。

如果使用原生态类型，就失掉了泛型在安全性和表述性方面的所有优势。

如果List这样的原生态类型，就会失掉类型安全性，但是如果使用像List<Object>这样的参数化类型，则不会。

第24条：消除非受检警告

用泛型编程时，会遇到许多编译器警告：非受检强制转化警告(unchecked cast warnings)、非受检方法调用警告、非受检普通数组创建警告，以及非受检转换

警告(unchecked conversion warnings)。当你越来越熟悉泛型之后，遇到的警告也会越来越少，但是不要期待从一开始用泛型编写代码就可以正确地进行编译。

如果无法消除警告，同时可以证明引起警告的代码是类型安全的，(只有在这种情况下才)可以用一个@SuppressWarnings(“unchecked”)注解来禁止这条警告。

应该始终在尽可能小的范围中使用SuppressWarning注解。

每当使用SuppressWarnings(“unchecked”)注解时，都要添加一条注释。说明为什么这么做是安全的。

第25条：列表优先于数组

数组和泛型有着非常不同的类型规则。数组是协变且可以具体化的；泛型是不可变的且可以被擦除的。因此，数组提供了运行时的类型安全，但是没有编译时的

类型安全，反之，对于泛型也一样。一般来说，数组和泛型不能很好地混合使用。如果你发现自己将它们混合起来使用，并且得到了编译时错误或者警告，你的

第一反应就应该是列表代替数组。

第26条：优先考虑泛型

使用泛型比使用需要在客户端代码中进行转换的类型来得更加安全，也更加容易。在设计新类型的时候，要确保它们不需要这种转换就可以使用。这通常意味着

要把类做成是泛型的。只要时间允许，就把现有的类型都泛型化。这对于这些类型的新用户来说会变得更加轻松，又不会破坏现有的客户端。

第27条：优先考虑泛型方法

泛型方法的一个显著特性是，无需明确指定类型参数的值，不像调用泛型构造器的时候是必须指定的。编译器通过检查方法参数的类型来计算类型参数的值。

泛型方法就像泛型一样，使用起来比要求客户端转换输入参数并返回值的方法来得更加安全，也更加容易。就像类型一样，你应该确保新方法可以不用转换

就能使用，这通常意味着要将它们泛型化。并且就像类型一样，还应该将现有的方法泛型化，使新用户使用起来更加轻松，且不会破坏现有的客户端。

第28条：利用有限制通配符来提升ＡＰＩ的灵活性

为了获得最大限度的灵活性，要在表示生产者或者消费者的输入参数上使用通配符类型。

如果类型参数只在方法声明中出现一次，就可以用通配符取代它。

在ＡＰＩ中使用通配符类型虽然比较需要技巧，但是使ＡＰＩ变得灵活的多。如果编写的是将广泛使用的类库，则一定要适当地利用通配符类型。记住基本的

原则：producer-extends，consumer-super(PECS)。还要记住所有的comparable和comparator都是消费者。

第29条：优先考虑类型安全的异构容器

集合API说明了泛型的一般用法，限制你每个容器只能有固定数目的类型参数。你可以通过将类型参数放在键上而不是容器上来避开这一限制。对于这种类型安全的

异构容器，可以用Class对象作为键。以这种方式使用的Class对象称作类型令牌。你也可以使用定制的键类型。例如，用一个DatabaseRow类型表示一个数据库行

(容器)，用泛型Column<T>作为它的键。