第23条 请不要在新代码中使用原生态类型
如果使用原生态类型 就失掉了泛型在安全性和表述性方面的所有优势
如果使用像List这样的原生态类型 就会失掉类型安全性 但是如果使用像List<Object>这样的参数化类型 则不会
在类文字(class literal)中必须使用原生态类型
Set<Object>是个参数化类型 表示可以包含任何对象类型的一个集合 Set<?>则是一个通配符类型 表示只能包含某种未知对象类型的一个集合 Set则是个原生态类型 它脱离了泛型系统 前两种是安全的 最后一种不安全
分类
| 术语 | 示例 |
|---|---|
| 参数化的类型 | List<String> |
| 实际类型参数 | String |
| 泛型 | List<E> |
| 形式类型参数 | E |
| 无限制通配符类型 | List<?> |
| 原生态类型 | List |
| 有限制类型参数 | <E extends Number> |
| 递归类型限制 | <T extends Comparable> |
| 有限制通配符类型 | List<? extends Number> |
| 泛型方法 | static <E> List <E> asList(E[] a) |
| 类型令牌 | String.class |
第24条 消除非受检警告
要尽可能地消除每一个非受检警告
如果无法消除警告 同时可以证明引起警告的代码是类型安全的(只有在这种情况下才) 可以用一个@SuppressWarnings(“unchecked”)注解来禁止这条警告
应该始终在尽可能小的范围中使用SuppressWarnings注解
每当使用SuppressWarnings(“unchecked”)注解时 都要添加一条注释 说明为什么这么做是安全的
第25条 列表优先于数组
数组是协变的 泛型是不可变的
数组是有缺陷的
泛型是通过擦除来实现的
数组提供了运行时的类型安全 但是没有编译时的类型安全 泛型与之相反 一般来说 数组和泛型不能很好地混合使用
第26条 优先考虑泛型
使用泛型比使用需要在客户端代码中进行转换的类型来得更加安全 也更加容易 在设计新类型的时候 要确保它们不需要这种转换就可以使用 这通常意味着要把类做成是泛型的
只要时间允许 就把现有的类型都泛型化 这对于这些类型的新用户来说会变得更加轻松 又不会破坏现有的客户端
第27条 优先考虑泛型方法
静态工具方法尤其适合于泛型化
泛型方法是通过类型推导实现的
就像类型一样 你应该确保新方法可以不用转换就能使用 这通常意味着要将它们泛型化 并且就像类型一样 还应该将现有的方法泛型化
第28条 利用有限制通配符来提升API的灵活性
为了获得最大系限度的灵活性 要在表示生产者或者消费者的输入参数上使用通配符类型
如果参数化类型表示一个T生产者 就使用<? extends T> 如果它表示一个T消费者 就使用<? super T>
不要用通配符类型作为返回类型
如果使用得当 通配符类型对于类的用户来说几乎是无形的 它们使方法能够接受它们应该接受的参数 并拒绝那些应该拒绝的参数 如果类的用户必须考虑通配符类型 类的API或许就会出错
如果类型参数只在方法声明中出现一次 就可以用通配符取代它
第29条 优先考虑类型安全的异构容器
集合API说明了泛型的一般用法 限制你每个容器只能有固定数目的类型参数 你可以通过将类型参数放在键上而不是容器上来避开这一限制 对于这种类型安全的异构容器 可以用Class对象作为键 以这种方式使用的Class对象称作类型令牌 你也可以使用定制的键类型 例如 用一个DatabaseRow类型表示一个数据库行(容器) 用泛型Column<T>作为它的键