之前就写过一篇泛型的文章,但是总觉得写得不够系统,所以最近对泛型又作了些研究,算是对这篇文章的补充了。
泛型,是为了让「类」、「接口」、「方法」具有更加通用的使用范围而诞生的,举个例子,假如我们不使用泛型,那么一个List中可以装得下任何对象,这么做的问题就在于,在使用时,需要对类型进行检查,不然就会转换异常。所以,我们需要将这种检查前置到编译期,这样在编写代码时,就可以安全的使用不同类型,例如List,我们一看就知道是一个String类型的list,不能放其他类型的元素。在Java中,由于历史原因,它并不存在真泛型,Java所有的泛型都是伪泛型,因为Java在编译期,会执行「泛型擦除」,从而导致在Java字节码中,不存在类型信息(但是类型会被保存在其它地方,这个后面讲)。
❝正是由于泛型擦除的问题,你甚至可以通过反射绕开泛型的限制,传递一个非当前泛型限制的对象。 ❞
泛型类型在Java中,通常以一个大写字母来进行标识,我们并不是一定要写「T」来表示泛型,但这是一个约定成俗的表示,类似的约束还有下面这些。
要理解Kotlin的泛型,我们最好首先从Java的泛型来学习,毕竟Kotlin的语法糖太多了,Java会更加白话文一点。首先,Java中的泛型具有「不变性」,也就是说,编译器会认为List和List是两个完全不同的类型,当然,不仅仅是List,比如下面这个例子。
open class A
class B : A()
那么Test<A>和Test<B>是不是一个类型呢?必须不是,虽然A和B是父子关系,但Test<A>和Test<B>就不是了,为什么呢?我们站在编译器的角度来想想,假如它们是同一个类型,那么在Test类中get出来的实例,到底是A还是B呢?所以编译器为了避免这种不确定性,就否定了Test<A>和Test<B>是一种类型的推断。但是这种处理在我们处理泛型业务时,会有很多限制,所以,泛型提供了「型变」来拓展泛型的使用。
协变指的是,当参数具有父子关系时,子类可以作为参数传递,而泛型的上界就是其父类。协变通过上界通配符<? extends 父类型>来实现。实例化时可确定为「父类型的未知类型」,所以它「只能读不能写」,因为编译器不确定到底是哪个子类。例如下面的代码。
List<Button> buttons = new ArrayList<Button>();
List<? extends TextView> textViews = buttons;
由于Button是TextView的子类,所以上面的代码可以正确运行。我们来解释下上面的代码。
❝上界通配符还有一个特例,那就是「?」,例如List<?>,实际上就是List<? extends Object>的缩写。在Kotlin中,使用的是「*」,即List<*>,实际上就是List<out Any> ❞
简而言之,协变就是——如果A是B的子类,那么Generic<A>就是Generic<? extends B>的子类型。
我们来看下面的代码。
List<? extends TextView> textViews = new ArrayList<TextView>();
TextView textView = textViews.get(0);
// Error
textViews.add(textView);
我们来解释下上面的代码,首先,我们定义了一个具有泛型上界的list,然后,我们从list中读取一个元素,这时候,这个元素的返回类型是什么呢?编译器并不知道,但由于泛型上限的存在,所以它一定是TextView及其子类,所以定义为TextView类型,也完全没有问题。接下来我们来实现写入,这时候,就报错了。看上去好像没错啊,add进去的元素是TextView类型,符合泛型上界的定义啊,但是,这个List的类型定义是<? extends TextView>,编译器并不知道具体是什么类型,所以它就认为,最好的办法就是什么都不让加,多做就是错,那不如不做。所以,经过协变之后的泛型,就失去了写入的能力,它只能用于向外提供数据,也就是「数据生产者Producer」。
逆变指的是,父类可以作为参数传递,但子类必须是其下界。逆变通过下界通配符<? super 子类型>来实现。实例化时可确定为「子类型的未知类型」,所以「只能写不能读」。
❝不能读指的是不能读取为指定的类型,而不是不能调用读的方法。 ❞
例如下面的代码。
List<? super Button> buttons = new ArrayList<TextView>();
同样我们来分析下上面的代码。
其实这整个就是协变的反向操作。一个是约束上界,另一个是约束下界,所以对比着,其实很好理解。简而言之,逆变就是——如果A是B的子类,那么Generic<B>就是Generic<? super A>的子类型。
类似的,我们再来看下逆变的限制。
List<? super Button> buttons = new ArrayList<TextView>();
Button button = new Button(context);
buttons.add(button);
Object object = buttons.get(0);
上面的代码,创建了一个list,它的元素类型的下界是Button,也就是说,这个list里面都是放的Button的父类类型。所以,当我们创建一个Button,并写入的时候,是完全可以的,因为它符合我们定义下界的约束。再来看看读取呢?当我们从list中读取一个元素时,由于编译器只知道它是Button的父类,但是具体是什么类型,它也不知道,所以,编译器不如将它作为Object这个万物基类了。所以说,逆变之后的泛型,失去了读的能力(因为读出来都是Object),所以逆变泛型通常都作为「数据消费者Consumer」。
泛型让我们有了可以支持多种类型的能力,型变让我们有了修改泛型的能力,总结来说:
在学习了Java泛型之后,我们再来看下Kotlin的泛型,这时候你再看,就没那么复杂了,核心就两条。
其实在理解了逆变和协变之后,你会发现out和in这两个关键字真的是「言简意赅」,out表示输出,即协变只用于输出数据,in表示输入,即逆变只用于写入数据。Kotlin官网上有个著名的——Consumer in, Producer out,说的就是这个意思。
我们通过这个例子来看下Kotlin对Java泛型的改进。
我们通过下面这个例子来看下Kotlin申明处型变的好处,这是一个生产者与消费者的例子,代码如下。
// 生产者
class Producer<T> {
fun produce(): T {}
}
val producer: Producer<out TextView> = Producer<Button>()
val textView: TextView = producer.produce()
首先我们来看生产者,对于T类型的Producer,我们要创建它的子类时,就需要使用协变,即Producer,否则它就只能生产Button类型的数据。所以,在Java中,每次获取数据的时候,都要声明一次协变,所以Kotlin对其进行了优化,可以在申明处进行协变,代码如下。
// 生产者
class Producer<out T> {
fun produce(): T {}
}
val producer1: Producer<TextView> = Producer<Button>()
val producer2: Producer<out TextView> = Producer<Button>()
Kotlin约定,当泛型参数T只会用来输出时,可以在申明类的时候,直接使用协变约束,这样在调用的时候,就不用额外使用协变了,当然写了也不会错。与此类似的,消费者也是如此。
// 消费者
class Consumer<T> {
fun consume(t: T) {}
}
val consumer: Consumer<in Button> = Consumer<TextView>()
consumer.consume(Button(context))
我们在使用的时候,也是必须使用逆变,借助Kotlin,同样可以在申明处进行逆变。
// 消费者
class Consumer<in T> {
fun consume(t: T) {}
}
val consumer1: Consumer<Button> = Consumer<TextView>()
val consumer2: Consumer<in Button> = Consumer<TextView>()
这样在调用的时候,就不用额外使用逆变了,当然写了也不会错。
由于在Java会进行泛型擦除,所以编译器无法在运行时知道一个确切的泛型类型,也就是说,我们无法在运行时,判断一个对象是否为一个泛型T的实例,例如下面的代码。
if (item instanceof T) {
System.out.println(item);
}
同样的,在Kotlin里面也是不行的,毕竟一母同胞。
if (item is T) {
println(item)
}
为了解决这个问题,在Java或者Kotlin中,我们通常会多传入一个Class类型的参数,然后通过Class.isInstance来判断类型是否匹配。但是由于Kotlin支持了内联函数,所以它提供了一个更加方便的方式来处理这种场景,那就是「reified」配合「inline」来实现。
inline fun <reified T> checkType(item: Any) {
if (item is T) {
println(item)
}
}
不是说好了不能直接对泛型来做类型判断吗,为什么这里却可以呢?这其实就是内联的作用,虽然这里是对T做判断,但实际上在编译时,这里已经被替换成了具体的类型,而不再是泛型T了,所以当然可以使用is来进行类型判断了。
在Kotlin中,有两种List,一种是可变的,一种是不可变的,即MutableList和List,其中List的申明如下,它已经实现的协变,所以Kotlin中的List只能读而不能写。
public interface List<out E> : Collection<E>
通过reified和inline配合,我们可以在运行时获取泛型的具体类型,这是Kotlin的特性,具体的使用方式,上面的文章已经讲了一个例子。下面我们再看看几个比较典型的例子。
fun reifiedClass() {
// normal
val serviceImpl1 = ServiceLoader.load(Service::class.java)
// reified
val serviceImpl2 = loadService<Service>()
}
inline fun <reified T> loadService() {
ServiceLoader.load(T::class.java)
}
interface Service {
fun work()
}
再看一个简化startActivity的方式。
inline fun <reified T : Activity> Activity.startActivity(bundle: Bundle? = null) {
val intent = Intent(this, T::class.java)
bundle?.let {
intent.putExtras(it)
}
startActivity(intent)
}
startActivity<SampleActivity>()
通过传入具体的Class类型,我们也可以在运行时获取泛型类型,这个方法是Java和Kotlin都支持的,这个在前面的文章中也提到了。
匿名内部类会在运行时实例化,这个时候,就可以拿到泛型的具体类型了,示例代码如下。
open class Test<T>
fun main() {
val innerClass = object : Test<String>() {}
val genericType: Type? = innerClass.javaClass.genericSuperclass
if (genericType is ParameterizedType) {
val type = genericType.actualTypeArguments[0]
// class java.lang.String
}
}
Class类提供了一个方法getGenericSuperclass ,通过它可以获取到带泛型信息的父类Type(Java的Class文件会保留继承的父类或者接口的泛型信息)。通过对获取的genericType来判断是否实现ParameterizedType接口,是说明支持泛型,从而获取出对应的泛型列表(因为泛型可能有多个)。这个方式是一个很巧妙的获取泛型类型的方法,在Gson中,就是通过它来获取类型的。
val content = Gson().toJson("xxx", object : TypeToken<String>() {}.type)
在使用Gson时,我们需要创建一个继承自TypeToken的匿名内部类, 并实例化泛型参数TypeToken,这样我们就可以通过getGenericSuperclass来获取父类的Type,也就是上面例子中的TypeToken了。
反射自然是可以拿到运行时的具体类型了,代码如下。
open class Test<T>
class NewTest : Test<String>() {
private val genericType: Type? = javaClass.genericSuperclass
fun test() {
if (genericType is ParameterizedType) {
val type = genericType.actualTypeArguments[0]
// class java.lang.String
}
}
}
通过反射来获取实际类型,是很大开源库中都在使用的方式,例如Retrofit,它在内部就是通过method.genericReturnType来获取泛型的返回类型,通过method.genericParameterTypes来获取泛型的参数类型。不过这里大家要好奇了,在文章的一开始,我们就说了,Java的伪泛型,会在编译时进行泛型擦除,那么反射又是怎么拿到这些泛型信息的呢?其实,编译器还是留了一手,申明处的泛型信息,实际上会以Signature的形式,保存到Class文件的Constant pool中,这样通过反射,就可以拿到具体的泛型类型了。
❝要注意的是,这里能保留的是申明处的泛型,如果是调用处的泛型,例如方法的传参,这种就不会被保存了。 ❞
PESC是泛型型变中的一个指导性原则,意为「Producer Extend Consumer Super」,当然在Kotlin中,这句话要改为「Consumer in, Producer out」。这个原则是从集合的角度出发的,其目的是为了实现集合的多态。
还是举一个例子来说明,我们可以认为Kotlin是Java的子类,但是List和List却是两个无关的类,它们之间没有继承关系,而使用List<? extends Java>后,相当于List和List之间也有了继承关系,从而可以读取List中不同类型的数据,List就是通过这种方式来实现了集合的多态。
我们来看这样一段代码,我们创建了一个copyAll的方法,传入to和from两个列表,代码如下。
fun <T> copyAll(to: MutableList<T>, from: MutableList<T>) {
to.addAll(from)
}
fun main() {
val numberList = mutableListOf<Number>() // to
val intList = mutableListOf(1, 2, 3, 4) // from
copyAll(numberList, intList)// Error
}
但是这段代码是不能编译通过的,原因在于to是一个List,而from是一个List,所以类型转换异常,不能编译。但实际上,我们知道Int是可以转换为Number的,但是编译器不知道,所以它只能报错,编译器需要的,就是我们告诉它,这样做是安全的,得到了我们的保证,编译器才能执行编译。这个保证是从两方面来说的,首先我们来看from。from是一个List,完全可以当做List,所以,要保证「from取出来的元素可以转为Number类型,而且from不能再有其它写入」,否则你向一个List中插入了一条Number类型的元素,那就不乱套了。所以,我们可以对from做协变,让它只读不写,代码如下。
fun <T> copyAll(to: MutableList<T>, from: MutableList<out T>) {
to.addAll(from)
}
这样就表示from,只接受T或者T的子类型,也就是说,from只能是Number或者Number的子类型,而此时from是Int类型,所以编译通过了。上面是从from的角度做的保证,那么从to方面呢?对于to来说,我们需要保证「to只能写入,而不能读取」。
fun <T> copyAll(to: MutableList<in T>, from: MutableList<T>) {
to.addAll(from)
}
这样就表示to,只接受T或者T的父类型,也就是说,to只能是Int或者Int的父类型,而此时to是Number类型,所以编译通过了。
❝另外,我们将from的签名改为List,也是可以编译的,其原因就是Kotlin中的List已经支持协变了。 ❞
相信大家通过这个例子,大概能理解协变和逆变的使用方式了。那么我们在实际的代码中,要在哪些场景使用协变和逆变呢?通常来说,泛型参数协变后则表示——「这个参数在当前类中,只能作为函数的返回值,或者是只读属性」。
abstract class TestOut<out T> {
abstract val num: T// 只读属性
abstract fun getItem(): T// 函数的返回值
abstract var num1 : T// Error 用于可变属性
abstract fun addItem(t: T)// Error 用于函数的参数
}
而逆变,表示这个参数「只能作为函数的参数,或者修饰可变属性」。
abstract class TestIn<in T> {
abstract val num: T//Error 只读属性
abstract fun getItem(): T//Error 函数的返回值
abstract fun addItem(t: T)// 用于函数的参数
}
本文原创公众号:群英传,授权转载请联系微信,授权后,请在原创发表24小时后转载。