Effective Java 第三版——29. 优先考虑泛型 (2)

因为E是不可具体化的类型,编译器无法在运行时检查强制转换。 再一次,你可以很容易地向自己证明,不加限制的转换是安全的,所以可以适当地抑制警告。 根据条目 27的建议,我们只在包含未经检查的强制转换的分配上抑制警告,而不是在整个pop方法上:

// Appropriate suppression of unchecked warning public E pop() { if (size == 0) throw new EmptyStackException(); // push requires elements to be of type E, so cast is correct @SuppressWarnings("unchecked") E result = (E) elements[--size]; elements[size] = null; // Eliminate obsolete reference return result; }

两种消除泛型数组创建的技术都有其追随者。 第一个更可读:数组被声明为E []类型,清楚地表明它只包含E实例。 它也更简洁:在一个典型的泛型类中,你从代码中的许多点读取数组; 第一种技术只需要一次转换(创建数组的地方),而第二种技术每次读取数组元素都需要单独转换。 因此,第一种技术是优选的并且在实践中更常用。 但是,它确实会造成堆污染(heap pollution)(条目 32):数组的运行时类型与编译时类型不匹配(除非E碰巧是Object)。 这使得一些程序员非常不安,他们选择了第二种技术,尽管在这种情况下堆的污染是无害的。

下面的程序演示了泛型Stack类的使用。 该程序以相反的顺序打印其命令行参数,并将其转换为大写。 对从堆栈弹出的元素调用String的toUpperCase方法不需要显式强制转换,而自动生成的强制转换将保证成功:

// Little program to exercise our generic Stack public static void main(String[] args) { Stack<String> stack = new Stack<>(); for (String arg : args) stack.push(arg); while (!stack.isEmpty()) System.out.println(stack.pop().toUpperCase()); }

上面的例子似乎与条目 28相矛盾,条目 28中鼓励使用列表优先于数组。 在泛型类型中使用列表并不总是可行或可取的。 Java本身生来并不支持列表,所以一些泛型类型(如ArrayList)必须在数组上实现。 其他的泛型类型,比如HashMap,是为了提高性能而实现的。

绝大多数泛型类型就像我们的Stack示例一样,它们的类型参数没有限制:可以创建一个Stack <Object>,Stack <int []>,Stack <List <String >>或者其他任何对象的Stack引用类型。 请注意,不能创建基本类型的堆栈:尝试创建Stack<int>或Stack<double>将导致编译时错误。 这是Java泛型类型系统的一个基本限制。 可以使用基本类型的包装类(条目 61)来解决这个限制。

有一些泛型类型限制了它们类型参数的允许值。 例如,考虑java.util.concurrent.DelayQueue,它的声明如下所示:

class DelayQueue<E extends Delayed> implements BlockingQueue<E>

类型参数列表(<E extends Delayed>)要求实际的类型参数E是java.util.concurrent.Delayed的子类型。 这使得DelayQueue实现及其客户端可以利用DelayQueue元素上的Delayed方法,而不需要显式的转换或ClassCastException异常的风险。 类型参数E被称为限定类型参数。 请注意,子类型关系被定义为每个类型都是自己的子类型[JLS,4.10],因此创建DelayQueue <Delayed>是合法的。

总之,泛型类型比需要在客户端代码中强制转换的类型更安全,更易于使用。 当你设计新的类型时,确保它们可以在没有这种强制转换的情况下使用。 这通常意味着使类型泛型化。 如果你有任何现有的类型,应该是泛型的但实际上却不是,那么把它们泛型化。 这使这些类型的新用户的使用更容易,而不会破坏现有的客户端(条目 26)。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpgxdg.html