泛型通配符

通配符

首先,要展示数组的一种特殊行为,可以向导出类型的数组赋予基类型的数组引用。

class Fruit {
}

class Apple extends Fruit {
}

class Jonathan extends Apple {
}

class Orange extends Fruit {
}

public class CovariantArrays {
    public static void main(String[] args) {
        Fruit[] fruits = new Apple[10];
        fruits[0] = new Apple();
        fruits[1] = new Jonathan();
        try {
            fruits[0] = new Fruit();
        } catch (Exception e) {
            System.out.println(e);
        }
        try {
            fruits[0] = new Orange();
        } catch (Exception e) {
            System.out.println(e);
        }
    }
}
// Outputs
java.lang.ArrayStoreException: com.daidaijie.generices.holder.Fruit
java.lang.ArrayStoreException: com.daidaijie.generices.holder.Orange

main()的第一行创建了一个Apple数组,并将其赋值给一个Fruit数组引用。这是有意义的,因为Apple也是一种Fruit,所以Apple数组应该也是一个Fruit数组。
但是,如果实际的数组类型是Apple[],你应该只能在其中放置Apple或者Apple的子类型,这在编译期和运行时都可以工作。但是要注意的是,编译器允许Fruit放置到这个数组中,这对于编译器来说是有意义的,因为它有一个Fruit引用——它有什么理由不允许将这个Fruit对象或者任意从Fruit继承出来的对象(例如Orange)放置到这个数组中呢?因此在编译期,这是允许的。但是,运行时数组机制知道它是Apple,因此会在向数组中放置异构类型时抛出异常。
实际上,向上转型并不合适用在这里。这里真正做的是将一个数组赋值为另一个数组。数组的行为应该是它可以持有其他对象,这里只是因为我们能够向上转型而已,所以很明显,数组对象可以保留有关它们包含的对象类型的规则。就好像数组对它们持有的对象是有意识的,因为在编译期检查和运行时检查之间,你不能滥用它们。
对数组的这种赋值并不是那么可怕,因为在运行时可以发现你已经插入不正确的类型,但是泛型的主要目的是将这种错误检测能够移入到编译期。因此当试图使用泛型容器来代替数组的时候,会发生什么呢。

public class NonCovariantGenerics {
    // compile error
    List<Fruit> flist = new ArrayList<Apple>;
}

第一次看这段代码的时候会认为,"不能讲一个Apple容器赋值给一个Fruit容器"。但是,泛型不仅和容器相关正确的说法是,"不能把一个涉及Apple的泛型赋值给一个涉及Fruit的泛型"。如果就像在数组的情况一样,编译器对代码的了解足够多,就可以确定所涉及到的容器,,那么它可能会留下一些余地。但是它不知道任何有关这方面的信息,因此她拒绝向上转型。然而这根本不是向上转型——AppleList不是FruitListAppleList将持有Apple的子类型,而Fruit将持有任何类型的Fruit,诚然,这包括Apple在内,但是它不是一个AppleList,它仍旧是FruitListAppleList在类型上不等价于FruitList,即使Apple是一种Fruit类型。
而真正的问题是在谈论容器的类型,而不是容器持有的类型。与数组不同,泛型没有内建的协变类型。这是因为数组在语言中是完全定义的,因此内建了编译期和运行期的检查,但是在使用泛型时,编译器和运行时系统都不知道你想用类型干什么,以及应该采用什么样的规则。
但是有时候,想在两个类型之间建立某种向上转型的关系,这正是通配符允许的。

public class GenericsAndCovariance {
    public static void main(String[] args) {
        List<? extends Fruit> flist = new ArrayList<>();
        // flist.add(new Apple());
        // flist.add(new Fruit());
        // flist.add(new Object());
        flist.add(null); //合法但是没有意义
        // 我们至少知道这会返回Fruit类型
        Fruit f = flist.get(0);
    }
}

flist类型现在是List<? extends Fruit>,可以将其读作"具有任何从Fruit继承的类型的类型的列表",但是这实际上并不意味着这个List将持有任何类型的Fruit。通配符引用的是明确的类型,一次它意味着"某种flist引用没有指定具体的类型"。因此这个被赋值的List必须持有诸如Fruit或者Apple这样的某种指定的类型,但是为了向上转型为flist,这个类型是什么没人关心。
如果唯一的限制是这个List要持有某种具体的Fruit或者Fruit的子类型,但是实际上并不关心它是什么,那么可以用这样的List做什么呢?如果不知道List要持有什么类型,那么怎么样才能向其中安全地添加对象呢,就像在CovariantArrays.java中向上转型数组一样,所以答案是不能,除非编译器而不是运行时系统可以阻止这种操作的发生,但是很快会发现这一问题。
现在事情有点极端了,因为不能向刚刚声明过将持有Apple对象的List放置一个Apple对象了。但是编译器并不知道这一点。List<?extends Fruit>可以合法地指向一个List<Orange>。因此一旦执行了这种类型的向上转型,就会丢失掉向其中传递任何对象的能力,就算是传递Object也不行。
但另一方面,如果调用的是一个返回Fruit的方法,则是安全的,因为这个List中任何的对象至少具有Fruit类型,因此编译器允许这样做。

“智能”的编译器

编译器不一定会阻止通配符修饰的泛型类中,调用任何接受参数的方法。

public class CompilerIntelligence {

    public static void main(String[] args) {
        List<? extends Fruit> flist = Arrays.asList(new Apple());
        Apple a = (Apple) flist.get(0); // no warning
        flist.contains(new Apple()); // args is 'Object'
        flist.indexOf(new Apple()); // args is 'Object'
    }
}

上面代码中,对contains()indexOf()的调用,这两个方法都接受Apple对象作为参数,而这些调用都可以正常执行。这不是因为编译器会去检查代码,以查看特定的方法是否修改了某个对象,而是因为contains()indexOf()将接受Object类型的参数。而add()却是接收了一个具有泛型参数类型的参数,因为当指定一个ArrayList<? extends Fruits>时,add()的参数就变成了?Extends Fruits,从这个描述中编译器并不能了解到这里需要Fruits的哪个具体子类型,因此它也不会接收任何类型的Fruit。即使是将Apple向上转型为Fruit,也无关紧要——编译器将直接拒绝对参数列表设计通配符的方法(例如add()的调用)。
在调用contains()indexOf()时,参数类型是Object,因此不涉及任何通配符,而编译器也将允许这个调用。
所以这意味着,这将由泛型类的设计者来决定哪种调用是“安全的”,并使用Object作为其参数类型。而为了在类型中使用通配符的情况下禁止这类调用,我们需要在参数中使用类型参数。
可以在一个简单的Holder类中看到这一点。

public class Holder<T> {
    private T value;

    public Holder() {
    }

    public Holder(T value) {
        this.value = value;
    }

    public T get() {
        return value;
    }

    public void set(T value) {
        this.value = value;
    }

    @Override
    public boolean equals(Object obj) {
        return value.equals(obj);
    }

    public static void main(String[] args) {
        Holder<Apple> apple = new Holder<>(new Apple());
        Apple d = apple.get();

        // can't not upcast
        // Holder<Fruit> fruit = apple;
        Holder<? extends Fruit> fruit = apple; // Ok
        Fruit p = fruit.get();
        try {
            Orange c = (Orange) fruit.get();
        } catch (Exception e) {
            System.out.println(e);
            // fruit.set(new Apple()); Can't call set()
            // fruit.set(new Fruit); Can't call set()
            System.out.println(fruit.equals(d)); // Ok
        }
    }
}
// Outputs
java.lang.ClassCastException: com.daidaijie.generices.holder.Apple cannot be cast to com.daidaijie.generices.holder.Orange
true

Holder有一个接受T类型对象的set()方法,和一个get()方法,以及一个接受Object对象的equals()方法。
可以看到代码中,Holder<Apple>不能向上转型为Holder<Fruits>,但是可以向上转型为Holder<? extends Fruits>。如果调用get(),它只会返回一个Fruit——这就是在给定“任何扩展自Fruit的对象”这一边界之后,它所能知道的一切。如果能够了解更多的信息,那么可以转型到某种具体的Fruit类型,而这不会调至任何的警告,但是存在得到ClassCastException的风险。set()方法不能工作于AppleFruit,因为set的参数也是“? extends Fruit”,这意味它可以是任何事物,而编译器无法验证“任何事物”的类型安全性。
但是,equals()方法工作良好,因为它将接受Object类型而并非T类型的参数。因此,编译器只关注传递进来和要返回的对象类型,它并不会分析代码,以查看是否执行了任何实际的写入和读取操作。

推荐阅读更多精彩内容