当前位置:首页 » 《随便一记》 » 正文

【编程语言】Kotlin快速入门 - 泛型

20 人参与  2024年11月29日 08:01  分类 : 《随便一记》  评论

点击全文阅读


Kotlin的泛型与Java十分类似,也是使用这种的语法结构:

class Fruit<T> {    fun eat(f : T): Unit {        println("eat...")    }    fun <T> buy(p : T): T {        return p    }}
泛型限制

和Java一样,Kotlin也允许泛型是某个类的子类

fun <T : Number> other(p : T): T {        return p}
泛型实化

Java的泛型是使用泛型擦除机制来实现的,所以只存在于编译时期,所以所有基于JVM的语言他们的泛型都是通过类型擦除机制实现的,Kotlin也不例外,这种机制使得我们不可能使用a is T或者T::class.java这些的写法了,因为T在运行时类型已经被擦除了。

然而Kotlin剔红了一个内联函数的概念,内联函数在编译时会自动被替换它被调用的地方,这样也就不存在什么泛型擦除的问题了,因为代码在编译的时候会直接使用实际的类型来替代内联函数中的泛型声明。

这意味着Kotlin是可以将内联函数中的泛型进行实化的,那怎样实现呢?首先函数必须是内联函数且声明泛型的地方需要使用reified进行修饰,举个例子:

fun main() {    var r = getGenericType<String>()    var m = getGenericType<Int>()    println("r is $r")    println("m is $m")}inline fun <reified T> getGenericType() = T::class.java

输出结果:r is class java.lang.String
m is class java.lang.Integer

而Java是不可能实现上述功能的,因为在编译后,泛型这个约束对于JVM已经不存在了。

泛型协变

泛型的协变与逆变功能就基本用不到,但是还是讲一下,避免在看别人代码的时候看不懂是什么意思。

首先我们需要讲一个概念,在泛型类或者泛型方法中,参数列表是接收数据的地方,因此可以称它的位置是in位置,而返回类型的地方是输出数据的地方,因此可以称它为out。

接下来我们定义三个类:

open class Person(val name: String, val age: Int)class Student(name: String, age: Int): Person(name, age)class Teacher(name: String, age: Int): Person(name, age)

接下来问你一个问题,假设在Java中一个方法接收Person类型的参数,而你传递一个Student可以吗,当然可以吧。

但是,如果方法接收的参数是一个List你传递一个List这样可以吗,这样是不行的,不行你去试一下,不行的原因主要是Java为了防止类型转换的安全隐患,我们举个例子,假设有个Data的泛型类:

class Data<T> {    var value: T? = null    fun set(v: T?) {        this.value = v    }    fun get(): T? {        return this.value    }}
fun main() {    var s = Student("XuanRan", 18)    var d = Data<Student>()    d.set(s)    handle(d) // 此行报错    println(d.get())}fun handle(data: Data<Person>) {    data.set(Teacher("Tom", 17))}

我们假设报错的那一行能够正常编译通过,按照程序逻辑,如果我们上面提到的问题允许的话,那么经过handle处理后的Data将不再是原来的Student,所以为了杜绝这种情况,Java直接禁用掉了这种方式,换句话讲,即使Student是Person的子类,但是Data并不是Data的子类。

不过,我们一起回顾一下代码,出现这种问题的主要原因是因为我们在handle方法内部,通过data给设置了Teacher对象,如果Data在泛型T上是只读的话,那肯定没有类型转换异常了,所以我们只要确保泛型类在其泛型数据上是只读的话那么它是没有类型转换安全隐患的,换句话说我们在Data类里面,只要保留get方法,不要暴露set方法供外部调用,只在构造方法中进行参数设置即可,要实现这一点,只要让这个泛型类的所有方法(构造除外)都不能去接收T类型的参数,换句话说,T只能出现在out位置,而不是in位置,如下代码所示:

class Data<out T>(val value: T) {    fun get(): T? {        return this.value    }}

我们在T之前使用out进行修饰,此时类中所有含参数T的方法都会报错,并且我们在这个类中添加常量value,此时,我们再或过头看之前的代码,会发现handle调用不报错了,而handle方法的实现中,调用Data内部的set方法报错,这很正常,因为我们删掉了set。

fun main() {    var s = Student("XuanRan", 18)    var d = Data(s)    handle(d)    println(d.get())}fun handle(data: Data<Person>) {    // todo}

这样我们就实现了泛型的协变。

除此之外,Kotlin已经给很多内置的API加上了协变的声明,其中就包括了各种集合类与接口,还记得我们之前提到的使用listOf只能创建只读的集合吗,我们现在就来看一下List的精简源码

public interface List<out E> : Collection<E> { override val size: Int override fun isEmpty(): Boolean override fun contains(element: @UnsafeVariance E): Boolean override fun iterator(): Iterator<E> public operator fun get(index: Int): E}

List在泛型E的前面加上了out关键字,说明List在泛型E上是协变的。不过这里还有一点需要说 明,原则上在声明了协变之后,泛型E就只能出现在out位置上,可是你会发现,在 contains()方法中,泛型E仍然出现在了in位置上。

这么写本身是不合法的,因为在in位置上出现了泛型E就意味着会有类型转换的安全隐患。但是 contains()方法的目的非常明确,它只是为了判断当前集合中是否包含参数中传入的这个元 素,而并不会修改当前集合中的内容,因此这种操作实质上又是安全的。那么为了让编译器能够理解我们的这种操作是安全的,这里在泛型E的前面又加上了一个@UnsafeVariance注解, 这样编译器就会允许泛型E出现在in位置上了。

泛型逆变

我们定义一个Transformer对象,并接收一个Person的泛型,此外要求接口实现类必须重写自己的trans方法,然后我们在main中实现了这个接口,这个接口trans的返回值将会返回Person的名字和姓名,并且定义了一个方法handle,用于输出一个学生的姓名,但是handle在调用的时候会报错语法错误,因为方法要求接收的是Transformer的泛型,而传递过来的却是Transformer的泛型,换句话说,Transformer并不是Transformer的子类型。

interface Transformer<T> {    fun trans(t: T): String}fun main() {    // 实现一个Transformer接口    val t = object : Transformer<Person> {        // 定义我们自己的trans方法        override fun trans(t: Person): String {            // 该方法会返回Person类的名称和年龄            return "${t.name} ${t.age}"        }    }    handle(t) // 此处语法错误}/** * 该函数接收一个Transformer的对象,要求泛型为Student */fun handle(s: Transformer<Student>) {    var student = Student("XuanRan", 12)    println(s.trans(student))}

要解决这个问题,我们就可以使用泛型的逆变,也就是in关键字,修改Transformer代码,如下所示:

interface Transformer<in T> {    fun trans(t: T): String}

然后代码就能正常编译输出了,这就是泛型的逆变。


点击全文阅读


本文链接:http://zhangshiyu.com/post/193700.html

<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1