程序员的职业素养真是完全不能相信的东西

事情要从一次面试说起,面试官问了这么一个问题,在JDK下面这个方法中:

public static <T extends Comparable<? super T>> void sort(List<T> list) 

这里面<T extends Comparable<? super T>>有什么用?

美好的愿景

很明显,从语义上来说,sort方法要对一个List排序,这个List中的元素类型为T,sort方法要求这个T类型必须是可比较的。这个可比较的含义是说,任意两个T类型的对象,可以通过compareTo方法来确定大小。理想情况下,一个T类型实现了Comparable接口的话,那么对于任意两个属于T类型的对象x和y,都可以通过compareTo方法来确定大小。因此,方法写成如下形式即可。

public static <T extends Comparable> void sort(List<T> list) 

Comparable接口的无奈

可是现实世界里,并不是T类型实现了Comparable接口就可以和T类型比较,而是T类型实现Comparable<E>之后,可以和E比较。尽管T实现Comparable<E>毫无道理可言,但是在语法上是正确的。
所以对于下面这个类,只能说代码写得烂,作者职业素养低,而编译器却无能为力,令人扼腕叹息。

public class Bar implements Comparable<String>

Java泛型系统出来背一次锅

为了将这样的类拒之门外,sort方法写成下面这样岂不是很好?sort需要的T类型,是一个能和T类型比较的类型,真是天衣无缝啊。

public static <T extends Comparable<T>> void sort(List<T> list) 

但是有这样一种情况,假设有个类型S,S实现了Comparable<S>,然后T继承了S,那么T就具备了和S比较的能力。但是这时T能通过编译么?答案是不能,因为在编译器看来,T只具备和S比较的能力,不具备和T比较的能力。尽管T是S的子类,但是编译器不认为如果一个类型具备了和S比较的能力,就具备了和T比较的能力。听上去感觉有点不合理,就好比经常有猎头问我:“好了,我现在知道你会用hadoop、spark这些来搞大数据了,那么请问你会Java么?”

这个就是Java泛型系统的一个坑特性——不具备协变、逆变的能力,所以尽管Integer是Number的子类,List<Integer>却不是List<Number>子类,一个能比较Number的比较器也不能被当做一个Integer的比较器。

所以最终用<T extends Comparable<? super T>>对T进行了约束,这样不管T的Comparable是自己实现的也好,还是继承的也好,都可以海纳百川有容乃大的被sort方法接受了。

美中不足

但是<T extends Comparable<? super T>>约束能力还是不够强,因为它在语义上表示的是“T能够和super T的任何类型比较”,所以下面这个类还是可以编译通过的,除了你的同事会对你的编程水平和职业素养产生质疑。

public class Bar extends RuntimeException implements Comparable<Exception>

就像equals和hashcode的代码契约一样,如果编译器在语法层面完全无法提供检查,只能靠程序员的职业素养来产生良好的代码,真是令人太不开心了。

    原文作者:大神带我来搬砖
    原文地址: https://www.jianshu.com/p/8acee5f85582
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞