Effective Java 第三版——28. 列表优于数组

Tips
《Effective Java, Third Edition》一书英文版已经出版,这本书的第二版想必不少人都读过,号称Java四大名著之一,不过第二版2009年出版,到如今已经将近8年的时间,但随着Java 6,7,8,甚至9的发布,Java语言发生了深入的变化。
在这里第一时间翻译成中文版。供你们学习分享之用。java

Effective Java, Third Edition

数组在两个重要方面与泛型不一样。 首先,数组是协变的(covariant)。 这个吓人的单词意味着若是SubSuper的子类型,则数组类型Sub []是数组类型Super []的子类型。 相比之下,泛型是不变的(invariant):对于任何两种不一样的类型Type1Type2List<Type1>既不是List <Type2>的子类型也不是父类型。[JLS,4.10; Naftalin07,2.5]。 你可能认为这意味着泛型是不足的,但能够说是数组缺陷。 这段代码是合法的:数组

// Fails at runtime!
Object[] objectArray = new Long[1];
objectArray[0] = "I don't fit in"; // Throws ArrayStoreException

但这个不是:安全

// Won't compile!
List<Object> ol = new ArrayList<Long>(); // Incompatible types
ol.add("I don't fit in");

不管哪一种方式,你不能把一个String类型放到一个Long类型容器中,可是用一个数组,你会发如今运行时产生了一个错误;对于列表,能够在编译时就能发现错误。 固然,你宁愿在编译时找出错误。dom

数组和泛型之间的第二个主要区别是数组被具体化了(reified)[JLS,4.7]。 这意味着数组在运行时知道并强制执行它们的元素类型。 如前所述,若是尝试将一个String放入Long数组中,获得一个ArrayStoreException异常。 相反,泛型经过擦除(erasure)来实现[JLS,4.6]。 这意味着它们只在编译时执行类型约束,并在运行时丢弃(或擦除)它们的元素类型信息。 擦除是容许泛型类型与不使用泛型的遗留代码自由互操做(条目 26),从而确保在Java 5中平滑过渡到泛型。性能

因为这些基本差别,数组和泛型不能很好地在一块儿混合使用。 例如,建立泛型类型的数组,参数化类型的数组,以及类型参数的数组都是非法的。 所以,这些数组建立表达式都不合法:new List <E> []new List <String> []new E []。 全部将在编译时致使泛型数组建立错误。学习

为何建立一个泛型数组是非法的? 由于它不是类型安全的。 若是这是合法的,编译器生成的强制转换程序在运行时可能会由于ClassCastException异常而失败。 这将违反泛型类型系统提供的基本保证。ui

为了具体说明,请考虑下面的代码片断:翻译

// Why generic array creation is illegal - won't compile!
List<String>[] stringLists = new List<String>[1];  // (1)
List<Integer> intList = List.of(42);               // (2)
Object[] objects = stringLists;                    // (3)
objects[0] = intList;                              // (4)
String s = stringLists[0].get(0);                  // (5)

让咱们假设第1行建立一个泛型数组是合法的。第2行建立并初始化包含单个元素的List<Integer>。第3行将List<String>数组存储到Object数组变量中,这是合法的,由于数组是协变的。第4行将List <Integer>存储在Object数组的惟一元素中,这是由于泛型是经过擦除来实现的:List<Integer>实例的运行时类型仅仅是List,而List<String> []实例是List [],因此这个赋值不会产生ArrayStoreException异常。如今咱们遇到了麻烦。将一个List<Integer>实例存储到一个声明为仅保存List<String>实例的数组中。在第5行中,咱们从这个数组的惟一列表中检索惟一的元素。编译器自动将检索到的元素转换为String,但它是一个Integer,因此咱们在运行时获得一个ClassCastException异常。为了防止发生这种状况,第1行(建立一个泛型数组)必须产生一个编译时错误。code

类型EList<E>List<String>等在技术上被称为不可具体化的类型(nonreifiable types)[JLS,4.7]。 直观地说,不可具体化的类型是其运行时表示包含的信息少于其编译时表示的类型。 因为擦除,可惟一肯定的参数化类型是无限定通配符类型,如List <?>Map <?, ?>(条目 26)。 尽管不多有用,建立无限定通配符类型的数组是合法的。blog

禁止泛型数组的建立可能会很恼人的。 这意味着,例如,泛型集合一般不可能返回其元素类型的数组(可是参见条目 33中的部分解决方案)。 这也意味着,当使用可变参数方法(条目 53)和泛型时,会产生使人困惑的警告。 这是由于每次调用可变参数方法时,都会建立一个数组来保存可变参数。 若是此数组的元素类型不可肯定,则会收到警告。 SafeVarargs注解能够用来解决这个问题(条目 32)。

当你在强制转换为数组类型时,获得泛型数组建立错误,或是未经检查的强制转换警告时,最佳解决方案一般是使用集合类型List <E>而不是数组类型E []。 这样可能会牺牲一些简洁性或性能,但做为交换,你会得到更好的类型安全性和互操做性。

例如,假设你想用带有集合的构造方法来编写一个Chooser类,而且有个方法返回随机选择的集合的一个元素。 根据传递给构造方法的集合,可使用选择器做为游戏模具,魔术8球或数据源进行蒙特卡罗模拟。 这是一个没有泛型的简单实现:

// Chooser - a class badly in need of generics!
public class Chooser {
    private final Object[] choiceArray;


    public Chooser(Collection choices) {
        choiceArray = choices.toArray();
    }


    public Object choose() {
        Random rnd = ThreadLocalRandom.current();
        return choiceArray[rnd.nextInt(choiceArray.length)];
    }
}

要使用这个类,每次调用方法时,都必须将Object的choose方法的返回值转换为所需的类型,若是类型错误,则转换在运行时失败。 咱们先根据条目 29的建议,试图修改Chooser类,使其成为泛型的。

// A first cut at making Chooser generic - won't compile
public class Chooser<T> {
    private final T[] choiceArray;

    public Chooser(Collection<T> choices) {
        choiceArray = choices.toArray();
    }

    // choose method unchanged
}

若是你尝试编译这个类,会获得这个错误信息:

Chooser.java:9: error: incompatible types: Object[] cannot be
converted to T[]
        choiceArray = choices.toArray();
                                     ^
  where T is a type-variable:
    T extends Object declared in class Chooser

没什么大不了的,将Object数组转换为T数组:

choiceArray = (T[]) choices.toArray();

这没有了错误,而是获得一个警告:

Chooser.java:9: warning: [unchecked] unchecked cast
        choiceArray = (T[]) choices.toArray();
                                           ^
  required: T[], found: Object[]
  where T is a type-variable:
T extends Object declared in class Chooser

编译器告诉你在运行时不能保证强制转换的安全性,由于程序不会知道T表明什么类型——记住,元素类型信息在运行时会被泛型删除。 该程序能够正常工做吗? 是的,但编译器不能证实这一点。 你能够证实这一点,在注释中提出证据,并用注解来抑制警告,但最好是消除警告的缘由(条目 27)。

要消除未经检查的强制转换警告,请使用列表而不是数组。 下面是另外一个版本的Chooser类,编译时没有错误或警告:

// List-based Chooser - typesafe
public class Chooser<T> {
    private final List<T> choiceList;


    public Chooser(Collection<T> choices) {
        choiceList = new ArrayList<>(choices);
    }


    public T choose() {
        Random rnd = ThreadLocalRandom.current();
        return choiceList.get(rnd.nextInt(choiceList.size()));
    }
}

这个版本有些冗长,也许运行比较慢,可是值得一提的是,在运行时不会获得ClassCastException异常。

总之,数组和泛型具备很是不一样的类型规则。 数组是协变和具体化的; 泛型是不变的,类型擦除的。 所以,数组提供运行时类型的安全性,但不提供编译时类型的安全性,反之亦然。 通常来讲,数组和泛型不能很好地混合工做。 若是你发现把它们混合在一块儿,获得编译时错误或者警告,你的第一个冲动应该是用列表来替换数组。

相关文章
相关标签/搜索