详解如何实现一个Kotlin函数类型

接口与函数类型

业务开发中，经常会有实现一个函数式接口（即接口只有一个方法需要实现）的场景，大家应该都会不假思索的写出如下代码：

interface Callback {
    fun response(): String
}

class Achieve: Callback {
    
    override fun response(): String {
        return ""
    }
}

这么写当然没什么毛病，甚至为了让kotlin支持对接口Callback的SAM转换，你还可以在接口前面增加一个fun修饰：

fun interface Callback {
    fun response()
}

但是对于Kotlin而言，本身函数类型是可以被实现的，也就是说我们可以使用函数类型替换函数式接口，让子类去实现，代码如下：

class Achieve: () -> String {
    override fun invoke(): String {
        return ""
    }
}

这种实现函数类型的类需要重写的方法都是invoke()，方法返回值类型对应的就是函数类型的返回值类型。

这种写法我在LeakCanary的源码中就看到了应用，比如监听Fragment是否销毁的类AndroidOFragmentDestroyWatcher：

在这里写下我对这两种方式优缺点的比较：

1.函数类型相比较于接口去实现的优点如下：

参数类型更加直观

某个类实现了函数类型，能直观的看到这个函数类型需要传入的参数有哪些，是什么类型，返回值又是什么类型，而如果实现了一个接口，一般大家都习惯跳转到接口定义的地方看接口方法的实现，所以这一点函数类型会更加方便些

检索更方便

函数类型需要重写的方法名一定叫invoke，所以如果我需要看下某个实现类对重写方法的具体实现逻辑，直接在当前类中搜索invoke关键字定位到这个方法即可；而如果是一个接口接口，我得跳转到接口的定义的地方看接口方法名是什么，才能去实现类中去搜索，所以在这点上函数类型会更加方便些

2.函数类型相比较于接口去实现的缺点如下：

函数类型语义性会比较差：

毕竟定义的接口名一般是和业务进行绑定的，能大概知道这个接口是干啥用的，更加清晰直观，当然这个问题我们可以使用typealias解决，但就会失去上面参数类型更加直观的优点

多态性会比较差（自己编的，不知道合不合理）

比如如果定义的一个接口去实现，我们很容易实现下面这种功能：

fun test(achieve: Achieve) {
    if (achieve is Callback) {
        //实现某些逻辑
    }
}

而如果使用函数类型去实现这种逻辑：

看起来是不是很奇怪，而且对于很多需要重写的方法签名都是相同的（方法参数和返回值都是相同的），根本无法实现这种功能，具体的看下面一点的描述。

无法实现多个相同的函数类型

业务场景中也存在实现多个接口，并且接口定义的方法参数和返回值类型都是相同的，比如下面：

fun interface Callback {
    fun response(): String
}

fun interface Callback2 {
    fun response2(): String
}

class Achieve2: Callback, Callback2 {
    override fun response(): String {
        return ""
    }

    override fun response2(): String {
        return ""
    }
}

如果使用函数类型根本无法实现上面的这种多个接口实现的功能：

直接进行报错。

总结

不管是实现函数类型还是接口，两者都各有其优缺点，大家需要根据业务场景进行具体的选择

到此这篇关于详解如何实现一个Kotlin函数类型的文章就介绍到这了,更多相关Kotlin函数类型内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论