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

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 ""
}
}

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

直接进行报错。

总结

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