作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO
联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬
我们花了两篇文章讲述了泛型是什么以及有什么用:
作用于编译期,由编译器解析,是一种兼具类型约束和自动转型的代码模板存入:约束存入的元素类型,将可能的类型错误提前到编译期取出:编译自动转型,消除手动强转,极大降低ClassCastException的风险
泛型只是程序员和编译器 的约定。
我们可以通过泛型告诉编译器自己的意图 :
呐,我现在假定这个List只能存String,你帮我盯着点,后面如果不小心放错类型,在编译期报错 提醒我。
当然,要想编译器帮我们约束类型,就必须按人家的规矩办事。 就好比Spring明明告诉你默认读取resources/application.yml,你非要把配置文件命名为resources/config.yml当然就报错啦。
而泛型也有一套自己的规则,我们必须遵守这些规则才能让编译器按我们的意愿做出约束。
这些规则是谁定的呢?当然是JDK的那群秃子咯。
今天我们来学习泛型通配符。
在讲述通配符的语法规则时,我会尽量给出自己的理解,让大家更容易接受它们。另外需要说明的是,在泛型相关的文章里我们总是以List元素存入、取出举例子,是因为容器类是我们接触最多的,这样更好理解。实际上对于泛型类、泛型方法都是适用的,并不一定要是容器类。
简单泛型
JDK1.5以后,我们全面跨入泛型时代。
假设现在有一个需求:设计一个print方法打印任意类型 的List。
你想显摆一下刚学的泛型,于是这样设计:
public class GenericClassDemo { public static void main(String[] args) { List
integerList = new ArrayList<>(); print(integerList); } public static void print(List list) { // 打印... } }
咋一看没问题,但需求是打印任意类型 的List。目前的print()只能接收List,你传List会报错:
你想了想,Object是所有对象的父类,我改成List吧:
悲剧,这下连List都不行了。这是为什么呢?我们来分析一下原因。
实际编码时,常见的错误写法如下:
// 错误写法1:间接传递(通常发生在方法传参,比如将stringList传给print(List list)) List stringList = new ArrayList<>(); List list = stringList; // 错误写法2:直接赋值 List list = new ArrayList();总之,list引用和实际指向的List容器类型必须一致(赋值操作左右两边的类型必须一致)。
JDK推荐的写法:
// 比较啰嗦的写法 List list = new ArrayList(); List list = new ArrayList(); // 省略写法,默认左右类型一致 List list = new ArrayList<>(); List list = new ArrayList<>();
我们在前面已经了解到,泛型底层其实还是Object/Object[],所以上面的几种写法归根到底都是Object[]赋值给Object[],理论上是没有问题的。
那么我们不禁要问:既然底层都支持了,为什么编译器要禁止这种写法呢?
我们从一正一反两个角度来思考这个问题。
正向思考首先,Object和String之间确实有继承关系,但List和List没有 ,不能用多态的思维考虑这个问题(List和ArrayList才是继承/实现关系)。
其次,讨论泛型时,大家应该尽量从语法角度分析。
对于:
List list = new ArrayList();
左边List的意思是希望编译器帮它约束存入的元素类型为Object,而右边new ArrayList()则希望约束存入的类型为String,此时就会出现两个约束标准,而它们却是对同一个List的约束,是自相矛盾的。
反向思考如果上面的论述还是缺乏说服力,那么我们干脆假设List list = new ArrayList()是合法的,又会发生什么呢?
先来看看数组是怎么处理类似问题的:
数组底层和泛型不同,泛型底层都是Object/Object[],而数组是真的分别创建了Object[]和String[],而且允许String[]赋值给Object[]。但这不是它骄傲的资本,反而是它的弱点,给了异常可趁之机:
public static void main(String[] args) throws Exception { // 直接往String[]存Integer会编译错误 String[] strings = new String[3]; strings[0] ="a"; strings[1] ="b"; strings[2] = 100; // COMPILE ERROR! // 但数组允许String[]赋值给Object[] Object[] objects = strings; // 这样就能通过编译了,但运行期会抛异常:ArrayStoreException objects[2] = 100; }
数组允许String[]赋值给Object[],但却把错误被拖到了运行期,不容易定位。
同样的,如果泛型也允许这样的语法,那就和数组没区别了:
首先,ls.add(new Object())成功了,那就意味着之前List所做的约束都白费了,因为StringList中混入了别的类型其次,编译器仍会按String自动转型,会发生ClassCastException
这么看来,泛型强制要求左右两边类型参数一致真是明智的举措,直接把错误扼杀在编译期。
泛型的指向与存取在之前介绍泛型时,我们观察的维度只有存入和取出,实际上泛型还有一个很重要的约束:指向。为什么之前不提这个概念呢?因为之前接触的泛型都太简单了,比如List只能指向 List,也就是泛型左右两边类型必须一致,没什么好讲的。
另外,千万别以为List只能存Number类型的元素,只要是Number的子类型都是可以的。因为对于List来说,反正取出时会统一转向上转型为Number,很安全。
至此,我们完善了泛型最重要的两个概念:指向、存取。
对于简单泛型而言:
List指向:只能指向List,左右两边泛型必须一致 (所以简单泛型解决不了print(List??>list)的通用性问题)List存入:可以存入Integer/Long/BigDecimal...等Number子类元素List取出:自动按Number转(存在多态,不会报错)
后面学习通配符时,也请大家时刻保持清醒,多想想当前list可以指向 什么类型的List,可以存取 什么类型的元素。如果你觉得上面的推演太绕了,那么就记住:简单泛型的左右两边类型必须一致。
通配符既然泛型强制要求左右两边类型参数必须一致,是否意味着永远无法封装一个方法打印任意类型的List?如何既能享受泛型的约束(防止出错),又能保留一定的通用性呢?
答案是:通配符。
我把List、BaseDao这样的称为简单泛型,把extends、super、?称为通配符。而简单泛型和通配符组合后又可以得到更为复杂的泛型,比如? extends T、? super T、?等。简而言之,通配符可以用来调节泛型的指向和存取之间的矛盾。
比如,有时我们需要list能指向不同类型的List(希望print()方法能接收更多类型的List)、有时我们又希望泛型能约束元素的存入和取出。但指向和存取往往不可兼得,具体要选用哪种泛型,需要根据实际情况做决定。
extends:上边界通配符通配符所谓的上边界、下边界其实是对“指向” 来说的。比如
List extends Number> list = new ArrayList();
extends是上边界通配符,所以对于List extends Number>,元素类型的天花板就是Number,右边List的元素类型只能比Number“低”。换句话说,List extends Number>只能指向 List、List等子类型List,不能指向List、List。
记忆方法: List extends Number> list = ...,把?看做右边List的元素(暂不确定,用?代替),? extends Number表示右边元素必须是Number的子类。
你可能会问:
之前简单泛型List不能指向List,怎么到了extends这就可以了。这不扯淡吗?
其实换个角度就是,Java规定简单泛型左右类型必须一致,但有些情况又要考虑通用性,所以又搞出了extends,允许List extends Number>指向子类型List。
之前我们假设过,如果允许简单泛型指向指向子类型List,那么存取会出问题:
现在extends通配符放宽了指向限制(List extends Human>允许指向List),是否意味着extends通配符也会发生强转错误呢?
卧槽,我以为有什么高招,结果用了extends后直接不让存了。不过想想,确实是无奈之举。
public static void main(String[] args) { List integerList = new ArrayList<>(); integerList.add(1); List longList = new ArrayList<>(); longList.add(1L); List extends Number> numberList = new ArrayList<>(); numberList = 随机指向integerList或longList等子类型List; numberList.add(1); // 由于无法确定numberList指向哪个List,所以干脆禁止add(万一指向integerList,那么add(1L)就不合适了,取出时可能转型错误) } 还不是很明白?那就再举个例子:
但是对于取出,extends可不含糊:
public static void main(String[] args) { List integerList = new ArrayList<>(); integerList.add(1); List longList = new ArrayList<>(); longList.add(1L); List extends Number> numberList = integerList; // 不管numberList指向integerList还是longList Number number = numberList.get(0); // 取出来的元素都可以转Number,因为Long/Integer都是它子类 }
看到这,我们应该有所体会:对于泛型而言,指向和存取是两个不同的方向,很难同时兼顾。要么指向放宽,存取收紧;要么指向收紧,存取放宽。
extends小结:
List extends Number>指向:Java允许extends指向子类型List,比如List extends Number>允许指向ListList extends Number>存入:禁止存入(防止出错)List extends Number>取出:由于指向的都是子类型List,所以按Number转肯定是正确的
相比简单泛型,extends虽然能大大提高指向的通用性,但为了防止出错,不得不禁止存入元素,也算是一种取舍。换句话说,print(List extends Number>list)对于传入的list只能做读操作,不能做写操作。
super:下边界通配符super是下边界通配符,所以对于List super Integer>,元素类型的地板就是Integer,右边List的元素类型只能比Integer“高”。换句话说,List super Integer>只能指向 List、List等父类型List。
记忆方法: List super Integer> list = ...,把?看做右边List的元素(暂不确定,用?代替),? super Integer表示右边元素必须是Integer的父类。
super的特点是:
List super Integer>指向:只能指向父类型List,比如List、ListList super Integer>存入:只能存Integer及其子类型元素List super Integer>取出:只能转Object
至此,我们发现Java同时满足了:
extends:指向子类型List简单泛型T:指向同类型Listsuper:指向父类型List
说完指向问题,我们再来探讨一下存取问题。思路还是一样,既然Java允许List super Integer>指向List等父类型,那么如何防止存取出错呢?
假设存在class Human implement Swimming, Speaking,那么Swimming和Speaking都是Human的父类/父接口。由于List super Human>可以指向父类型List,要么指向SwimmingList,要么指向SpeakingList。
public static void main(String[] args) { List swimmingList = new ArrayList<>(); // 假设加入了很多实现了Swimming接口的元素,比如Dolphin(海豚) // swimmingList.add(dolphin)... List speakingList = new ArrayList<>(); // 假设加入了很多实现了Speaking接口的元素,比如Parrot(鹦鹉) // speakingList.add(parrot)... List super Human> humanList = swimmingList / speakingList; // 指向随机的List humanList.add(...) // 是否应该允许存入 Parrot(鹦鹉)? } 此时对于List super Human>,是否应该允许加入 Parrot(鹦鹉)呢?答案是最好不要。因为humanList的指向是不确定的,如果刚好指向的是swimmingList,那么list.add(parrot)显然是不合适的。
只有存入Human及其子类才是安全的:
介绍完super的存入,最后聊聊super的取出。由于List super Human>可以指向任意Human父类型的List,可能是SwimmingList,也可能是SpeakingList。这意味取出的元素可能是Swimming,也可能是Speaking,是不确定的,所以用Swimming或Speaking都不太合适。
那能不能强转为Human呢?答案是不行。假设humanList指向的是swimmingList,而swimmingList里存的是Shark、Dolphin、Human,此时list.get(0)得到的是 Shark implements Swimming,强转为Human显然不合适。
super小结
List super Human>指向:只能指向父类型List,比如List、ListList super Human>存入:只能存Human及其子类型元素List super Human>取出:只能转Object
?:无界通配符讲完最难的两个通配符,?就很简单了。它类似于List extends Object>,允许指向任意类型的List。
再分析一下存和取:
由于指向的List不确定,并且这些List没有共同的子类,所以找不到一种类型的元素,能保证add()时百分百不出错,所以禁止存入。由于指向的List不确定,并且这些List没有共同的父类(除了Object),所以只能用Object接收。
通配符的使用场景泛型本身比较复杂,能把简单的T用熟练的已经不多,更别说用上通配符了。但从语法本身来说,通配符就是为了让赋值更具通用性。原先泛型赋值只能是同类型之间赋值,不利于抽取通用方法。而使用通配符后,就可以在一定程度上开放赋值限制。
?是开放限度最大的,可指向任意类型List,但在对List的方法调用上也是限制最大的,具体表现在:
入参和泛型相关的都不能使用(禁止存入)返回值和泛型相关的都只能用Object接收(只能强转为Object)
extends和super指向性各砍了一半,分别指向子类型List和父类型List,但方法使用上又相对开放了一部分:
extends不允许存入,但取出时类型稍微精确些,可以往边界类型转super允许存入子类型元素,但取出时只能转为Object
所以如果要用到通配符,需要结合业务考虑,如果你只是希望造一个方法,接收任意类型的List,且方法内不调用List的特定方法,那就用?。而对于extends和super的取舍,《Effective Java》提出了所谓的:PECS(Producer Extends Consumer Super)
频繁往外读取内容的(向外提供内容,所以是Producer),适合用 extends T>:extends返回值稍微精确些, 对调用者友好经常往里插入的(消耗数据,所以是Consumer),适合用 super T>:super允许存入 子类型元素
给大家举一个JDK对通配符的使用案例:
ArrayList中定义了一个addAll(Collection extends E>c)方法,我单独把这个方法拿出来:
class ArrayList extends ... { ... public boolean addAll(Collection extends E> c) { Object[] a = c.toArray(); int numNew = a.length; ensureCapacityInternal(size + numNew); // Increments modCount System.arraycopy(a, 0, elementData, size, numNew); size += numNew; return numNew != 0; } }
以Person为例,假设是List list = new ArrayList<>(),那么这个方法就变成了:
public boolean addAll(Collection extends Person> c) { Object[] a = c.toArray(); int numNew = a.length; ensureCapacityInternal(size + numNew); // Increments modCount System.arraycopy(a, 0, elementData, size, numNew); size += numNew; return numNew != 0; }
此时,addAll()只能接收Person集合或者它的Person子类的集合,比如Student extends Person:
List personList = new ArrayList<>(); List studentList = new ArrayList(); personList.addAll(studentList)
为什么会选择extends呢?还是PECS原则,因为allAll()很显然是消费者场景,我更关心对参数的具体操作,而不怎么关心返回值(就是boolean提示操作成功与否)。这也是我日常使用通配符时的一个思路,PECS确实很实用。
最后,很多人会以为?等同于T,其实两者是有区别的。我们本质还是通过给T“赋值”来确定类型,只不过此时赋值给T的不再是某个具体的类型,而是某个“匹配规则”, 帮助编译器确定向上、向下可以指向的List类型范围以及存取的元素类型限定。
强调当你使用简单泛型时,首要考虑你想把元素规定为何种类型,顺便考虑子类型的存入是否会有影响(一般不会)。而如果要使用通配符,应该先考虑接收的范围,再考虑存取操作如何取舍(PECS原则)。
个人愚见是,通配符的出发点本来是为了解决指向问题,但开放指向后为了避免ClassCastException,不得已又对存取加了限制,实际开发时要灵活利用边界限制并结合实际需求选择合适的泛型。
提问:
List list = new ArrayList(); 能添加各种类型的数据吗?List list = new Array()会报错吗?为什么?什么时候用?、extends、super?PECS是什么?List>和List的区别?
作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO 进群,大家一起学习,一起进步,一起对抗互联网寒冬