目录
接口与函数类型
业务开发中，经常会有实现一个函数式接口（即接口只有一个方法需要实现）的场景，大家应该都会不假思索的写出如下代码：
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 ""
}
}
如果使用函数类型根本无法实现上面的这种多个接口实现的功能：
直接进行报错。
总结
不管是实现函数类型还是接口，两者都各有其优缺点，大家需要根据业务场景进行具体的选择
