Java泛型-官方教程

在J2SE 5.0中引入的这种对类型系统期待已久的增强允许类型或方法对各种类型的对象进行操作，同时提供编译时类型安全。它为集合框架增加了编译时类型安全性，并消除了强制转换的苦差事。

机器翻译，有疑问参考出处 https://docs.oracle.com/javase/tutorial/extra/generics/index.html

介绍

JDK 5.0为Java编程语言引入了几个新的扩展。其中之一就是引入泛型。

这篇文章是对泛型的介绍。您可能熟悉来自其他语言的类似结构，尤其是c++模板。如果是这样，你会发现它们既有相似之处，也有重要的不同之处。如果您不熟悉来自其他地方的类似结构，那就更好了;你可以重新开始，不用忘记任何错误的想法。

泛型允许对类型进行抽象。最常见的例子是容器类型，比如集合层次结构中的容器类型。

下面是这种用法的典型用法:

List myIntList = new LinkedList(); // 1
myIntList.add(new Integer(0)); // 2
Integer x = (Integer) myIntList.iterator().next(); // 3     

第3行上的强制类型转换有点烦人。通常，程序员知道哪种类型的数据被放置到特定的list中。然而，转换至关重要。编译器只能保证迭代器返回一个Object。为了确保对Integer类型变量的赋值是类型安全的，需要进行类型转换。

当然，转换不仅会带来混乱。它还引入了运行时错误的可能性，因为程序员可能会弄错。

如果程序员能够真正表达他们的意图，并将列表标记为限制包含特定数据类型，情况会怎样?这是泛型背后的核心思想。下面是上面使用泛型的程序片段的一个版本:

List<Integer> myIntList = new LinkedList<Integer>(); // 1
myIntList.add(new Integer(0)); // 2
Integer x = myIntList.iterator().next(); // 3

请注意变量myIntList的类型声明。它不仅仅是一个列表，而是一个整数列表，写成List。我们说List是一个带类型参数的泛型接口——在本例中是Integer。我们还在创建list对象时指定类型参数。

还要注意，第3行上的强制类型转换转换已经消失了。

现在，您可能会认为只是做了胡乱的移动。不是在第3行将类型转换为Integer，而是在第1行将Integer作为类型参数。然而，这里有一个很大的区别。编译器现在可以在编译时检查程序的类型正确性。当我们说myIntList声明为List类型时，这告诉我们一些关于myIntList变量的信息，无论何时何地使用它都保持为真，并且编译器将保证它是正确的。相反，强制转换告诉我们程序员认为在代码的某一点上是正确的东西。

最终的效果，特别是在大型程序中，是提高了可读性和鲁棒性。

定义简单泛型

下面是java.util包中接口列表和迭代器定义的一小段摘录:

public interface List <E> {
    void add(E x);
    Iterator<E> iterator();
}

public interface Iterator<E> {
    E next();
    boolean hasNext();
}

这些代码应该都很熟悉，除了尖括号中的内容。这些是接口List和Iterator的形式类型形参的声明。

类型参数可以在泛型声明的整个过程中使用，与使用普通类型的情况差不多(尽管有一些重要的限制;见小字部分。

在简介中，我们看到了泛型类型声明列表的调用，例如List<Integer>。在调用(通常称为参数化类型)中，所有出现的正式类型参数(在本例中为E)都被实际类型参数(在本例中为Integer)取代。

你可以想象List<Integer>表示一个列表的版本，其中E被统一替换为整数:

public interface IntegerList {
    void add(Integer x);
    Iterator<Integer> iterator();
}

这种直觉很有帮助，但也会产生误导。

它很有帮助，因为参数化类型List<Integer>确实有类似于这个扩展的方法。

这是一种误导，因为泛型的声明实际上从来不会以这种方式展开。代码没有多个副本——源代码中没有，二进制文件中没有，磁盘上没有，内存中也没有。如果你是一名c++程序员，你就会明白这与c++模板有很大的不同。

泛型类型声明被永久编译，并转换为单个类文件，就像普通类或接口声明一样。

类型参数类似于方法或构造函数中使用的普通参数。就像方法拥有描述其操作的值类型的形式值参数一样，泛型声明也拥有形式类型参数。在调用方法时，将实际参数替换为形式参数，并计算方法体。当调用泛型声明时，将用实际的类型参数代替正式的类型参数。

关于命名约定的说明。我们建议您对正式类型参数使用简洁(如果可能的话，使用单个字符)而又唤起回忆的名称。最好避免在这些名称中使用小写字符，以便于将正式类型参数与普通类和接口区分开来。许多容器类型使用E作为元素，如上面的例子所示。我们将在后面的例子中看到一些额外的约定。

泛型和子类型

让我们测试一下你对泛型的理解。下面的代码片段合法吗?

List<String> ls = new ArrayList<String>(); // 1
List<Object> lo = ls; // 2 

第1行当然是合法的。问题中比较棘手的部分是第2行。这可以归结为一个问题:字符串列表是对象列表吗?大多数人都会本能地回答:“当然可以!”

好吧，看看下面几行:

lo.add(new Object()); // 3
String s = ls.get(0); // 4: Attempts to assign an Object to a String!

首先，第1行创建一个String类型List，第2行将lo指向ls。因此，ls中不再只保存字符串，当我们尝试从它那里获取一些东西时，我们得到了一个突然的惊喜。

Java编译器当然会阻止这种情况的发生。第2行将导致编译时错误。

通常，如果Foo是Bar的子类型(子类或子接口)，而G是某个泛型类型声明，直觉认为G<Foo>是G<Bar>的一个子类型。这可能是关于泛型您需要学习的最困难的事情，因为它违背了我们根深蒂固的直觉。

我们不应该假定集合不变。我们的本能可能会让我们认为这些东西是不可改变的。

例如，如果机动车辆部向人口普查局提供一份司机名单，这似乎是合理的。我们认为一个名单司机是一个List，假设Driver是Person的子类型。事实上，传递的是驱动程序注册表的副本。否则，人口普查局可能会在名单上增加新的非司机，破坏DMV的记录。

为了应对这种情况，考虑更灵活的泛型类型是很有用的。到目前为止，我们看到的规则是非常严格的。

通配符

考虑编写一个输出集合中所有元素的例程的问题。以下是你在该语言的旧版本(即5.0之前的版本)中可能会如何编写它:

void printCollection(Collection c) {
    Iterator i = c.iterator();
    for (k = 0; k < c.size(); k++) {
        System.out.println(i.next());
    }
}

下面是一个使用泛型(和新的for循环语法)编写它的幼稚尝试:

void printCollection(Collection<Object> c) {
    for (Object e : c) {
        System.out.println(e);
    }
}

问题是这个新版本比旧版本用处小得多。旧代码可以使用任何类型的集合作为参数来调用，而新代码只接受collections <Object>，正如我们刚才所演示的，它不是所有类型的集合的超类型!

那么，各种集合的超类型是什么呢?书面Collection<?>，即元素类型匹配任何元素的集合。它被称为通配符类型的原因很明显。我们可以写:

void printCollection(Collection<?> c) {
    for (Object e : c) {
        System.out.println(e);
    }
}

现在，我们可以用任何类型的集合来调用它。请注意，在printCollection()内部，我们仍然可以从c中读取元素并给它们类型对象。这总是安全的，因为无论集合的实际类型是什么，它都包含对象。然而，向它添加任意对象是不安全的:

Collection<?> c = new ArrayList<String>();
c.add(new Object()); // Compile time error	

因为我们不知道c的元素类型代表什么，所以我们不能向它添加对象。add()方法接受E类型的参数，即集合的元素类型。当实际类型参数为?时，它表示某个未知类型。传递给add的任何参数都必须是这个未知类型的子类型。因为我们不知道那是什么类型，所以我们不能传入任何东西。唯一的例外是null，它是每种类型的成员。

另一方面，给定一个列表，我们可以调用get()并使用其结果。结果类型是未知类型，但我们总是知道它是一个对象。因此，可以安全地将get()的结果赋值给类型为Object的变量，或将其作为需要类型对象的参数传递。

有界通配符

考虑一个可以绘制矩形和圆形等形状的简单绘图应用程序。为了在程序中表示这些形状，你可以定义这样的类层次结构:

// 形状
public abstract class Shape {
    public abstract void draw(Canvas c);
}
// 圆形
public class Circle extends Shape {
    private int x, y, radius;
    public void draw(Canvas c) {
        ...
    }
}
// 长方形
public class Rectangle extends Shape {
    private int x, y, width, height;
    public void draw(Canvas c) {
        ...
    }
}

这些类可以绘制在画布上:

// 画布
public class Canvas {
    public void draw(Shape s) {
        s.draw(this);
   }
}

任何绘图通常都会包含许多形状。假设它们以列表的形式表示，那么在画布中使用一个方法将它们全部绘制出来就很方便了:

public void drawAll(List<Shape> shapes) {
    for (Shape s: shapes) {
        s.draw(this);
   }
}

现在，drawAll()只能传入List，而不能传入List。这很不幸，因为该方法所做的只是从列表中读取形状，所以它也可以在list <Circle>上调用。我们真正想要的是让该方法接受任何形状的列表:

public void drawAll(List<? extends Shape> shapes) {
    ...
}

这里有一个很小但非常重要的区别:我们用List<? extends Shape>替换了List。现在drawAll()将接受Shape的任何子类的列表，所以我们现在可以在调用方法时传入List。

List<? extends Shape>是有界通配符的一个例子。?表示未知类型，就像我们前面看到的通配符一样。然而，在这种情况下，我们知道这个未知的类型实际上是Shape的子类型。(注意:它可以是Shape本身，也可以是某个子类), 我们说Shape是通配符的上界。

通常，使用通配符的灵活性是要付出代价的。这样做的代价是，现在在方法体中写入shapes是违法的。例如，这是不允许的:

public void addRectangle(List<? extends Shape> shapes) {
    // Compile-time error!
    shapes.add(0, new Rectangle());
}

您应该能够找出为什么上面的代码是不允许的。add()的第二个参数的类型是 ? extends Shape，一个Shape的未知子类型。因为我们不知道它是什么类型，不知道它是否是Rectangle的超类;它可能是Rectangle，也可能不是，所以在那里传递Rectangle是不安全的。

有界通配符正是处理DMV将其数据传递给人口普查局的示例所需要的。我们的示例假设数据是通过从名字(表示为字符串)到人(表示为引用类型，如Person或其子类型，如Driver)的映射来表示的。Map< K, V>是一个泛型类型的例子，它接受两个类型参数，表示映射的键和值。

再次注意形式类型参数的命名约定——K表示键，V表示值。

public class Census {
    public static void addRegistry(Map<String, ? extends Person> registry) {
}
...

Map<String, Driver> allDrivers = ... ;
Census.addRegistry(allDrivers);

泛型方法

考虑编写一个方法，该方法接受对象数组和集合，并将数组中的所有对象放入集合中。以下是第一个尝试:

static void fromArrayToCollection(Object[] a, Collection<?> c) {
    for (Object o : a) { 
        c.add(o); // compile-time error
    }
}

到目前为止，您已经学会避免初学者所犯的尝试使用Collections <Object>作为集合参数的类型。您可能意识到或没有意识到使用Collection<?>也行不通。回想一下，您不能只是将对象推入一个未知类型的集合。

处理这些问题的方法是使用泛型方法。就像类型声明一样，方法声明也可以是泛型的——也就是说，由一个或多个类型参数参数化。

static <T> void fromArrayToCollection(T[] a, Collection<T> c) {
    for (T o : a) {
        c.add(o); // Correct
    }
}

我们可以使用元素类型是数组元素类型超类型的任何类型的集合调用此方法。

Object[] oa = new Object[100];
Collection<Object> co = new ArrayList<Object>();

// T inferred to be Object
fromArrayToCollection(oa, co); 

String[] sa = new String[100];
Collection<String> cs = new ArrayList<String>();

// T inferred to be String
fromArrayToCollection(sa, cs);

// T inferred to be Object
fromArrayToCollection(sa, co);

Integer[] ia = new Integer[100];
Float[] fa = new Float[100];
Number[] na = new Number[100];
Collection<Number> cn = new ArrayList<Number>();

// T inferred to be Number
fromArrayToCollection(ia, cn);

// T inferred to be Number
fromArrayToCollection(fa, cn);

// T inferred to be Number
fromArrayToCollection(na, cn);

// T inferred to be Object
fromArrayToCollection(na, co);

// compile-time error
fromArrayToCollection(na, cs);

注意，我们不需要将实际的类型参数传递给泛型方法。编译器根据实际实参的类型为我们推断出type实参。它通常会推断出使调用类型正确的最具体的类型参数。

出现的一个问题是:什么时候应该使用泛型方法，什么时候应该使用通配符类型? 为了理解答案，让我们来看看来自Collection库的一些方法。

interface Collection<E> {
    public boolean containsAll(Collection<?> c);
    public boolean addAll(Collection<? extends E> c);
}

我们可以在这里使用泛型方法:

interface Collection<E> {
    public <T> boolean containsAll(Collection<T> c);
    public <T extends E> boolean addAll(Collection<T> c);
    // Hey, type variables can have bounds too!
}

然而，在containsAll和addAll中，类型参数T只使用一次。返回类型不依赖于类型参数，也不依赖于该方法的任何其他参数(在本例中，只有一个参数)。这告诉我们，type参数被用于多态性;它唯一的作用是允许在不同的调用位置使用各种实际参数类型。如果是这种情况，应该使用通配符。通配符被设计为支持灵活的子类型，这正是我们在这里试图表达的。

泛型方法允许使用类型参数来表示一个或多个参数的类型之间对方法及其返回类型的依赖关系。如果没有这样的依赖关系，就不应该使用泛型方法。

可以同时使用泛型方法和通配符。下面是Collections.copy()方法:

class Collections {
    public static <T> void copy(List<T> dest, List<? extends T> src) {
    ...
}

请注意这两个参数类型之间的依赖关系。从源列表src复制的任何对象都必须可分配给目标列表dest的元素类型T。所以src的元素类型可以是t的任何子类型——我们不关心是哪个。copy的签名使用类型参数表示依赖关系，但是使用通配符表示第二个参数的元素类型。

我们可以用另一种方式来编写这个方法的签名，而根本不使用通配符:

class Collections {
    public static <T, S extends T> void copy(List<T> dest, List<S> src) {
    ...
}

这很好，但是虽然第一个类型参数在dest类型和第二个类型参数的范围中都使用，S, S本身只在src类型中使用一次——其他任何东西都不依赖于它。这表明我们可以用通配符替换S。使用通配符比声明显式类型参数更清晰、更简洁，因此应该尽可能使用通配符。

通配符还有一个优点，即它们可以在方法签名之外使用，如字段类型、局部变量和数组。下面是一个例子。

回到我们的形状绘制问题，假设我们想保存绘制请求的历史记录。我们可以在class Shape内部的静态变量中维护历史，并让drawAll()将传入的参数存储到历史字段中。

static List<List<? extends Shape>> history = new ArrayList<List<? extends Shape>>();

public void drawAll(List<? extends Shape> shapes) {
    history.addLast(shapes);
    for (Shape s: shapes) {
        s.draw(this);
    }
}

最后，让我们再次注意类型参数使用的命名约定。我们用T表示类型，当没有任何关于类型的更具体的东西来区分它的时候。这在泛型方法中很常见。如果有多个类型参数，我们可以在字母表中使用与T相邻的字母，例如s。如果泛型方法出现在泛型类中，最好避免为方法和类的类型参数使用相同的名称，以避免混淆。这同样适用于嵌套泛型类。

与遗留代码进行互操作

到目前为止，我们的所有示例都假定了一个理想化的世界，即每个人都在使用支持泛型的最新版本的Java编程语言。

唉，事实并非如此。数百万行代码已经用该语言的早期版本编写，它们不会在一夜之间全部转换。

稍后，在将遗留代码转换为使用泛型一节中，我们将处理将旧代码转换为使用泛型的问题。在本节中，我们将关注一个更简单的问题:遗留代码和泛型代码如何互操作?这个问题有两个部分:在泛型代码中使用遗留代码，以及在遗留代码中使用泛型代码。

在通用代码中使用遗留代码

如何使用旧代码，同时在自己的代码中仍然享受泛型的好处?

作为一个示例，假设您想使用com.Example.widgets包。Example.com market的工作人员开发了一套库存控制系统，如下图所示:

package com.Example.widgets;

public interface Part {...}

public class Inventory {
    /**
     * Adds a new Assembly to the inventory database.
     * The assembly is given the name name, and 
     * consists of a set parts specified by parts. 
     * All elements of the collection parts
     * must support the Part interface.
     **/ 
    public static void addAssembly(String name, Collection parts) {...}
    public static Assembly getAssembly(String name) {...}
}

public interface Assembly {
    // Returns a collection of Parts
    Collection getParts();
}

现在，您需要添加使用上述API的新代码。最好确保总是使用适当的参数调用addAssembly()——也就是说，传入的集合确实是部件的集合。当然，泛型是为此量身定做的:

package com.mycompany.inventory;

import com.Example.widgets.*;

public class Blade implements Part {
    ...
}

public class Guillotine implements Part {
}

public class Main {
    public static void main(String[] args) {
        Collection<Part> c = new ArrayList<Part>();
        c.add(new Guillotine()) ;
        c.add(new Blade());
        Inventory.addAssembly("thingee", c);
        Collection<Part> k = Inventory.getAssembly("thingee").getParts();
    }
}

当我们调用addAssembly时，它期望第二个参数是类型为Collection的。实际参数的类型是集合。这是可行的，但为什么呢?毕竟，大多数集合不包含Part对象，所以通常，编译器无法知道类型集合引用的是哪种类型的集合。

在适当的泛型代码中，集合总是伴随着类型参数。当像Collection这样的泛型类型不带类型参数时，它被称为原始类型。

大多数人的第一反应是，Collection实际上意味着Collection