詳解如何實現(xiàn)一個Kotlin函數(shù)類型

第詳解如何實現(xiàn)一個Kotlin函數(shù)類型目錄接口與函數(shù)類型總結(jié)

接口與函數(shù)類型

業(yè)務開發(fā)中，經(jīng)常會有實現(xiàn)一個函數(shù)式接口（即接口只有一個方法需要實現(xiàn)）的場景，大家應該都會不假思索的寫出如下代碼：

interfaceCallback{

funresponse():String

classAchieve:Callback{

overridefunresponse():String{

return""

}

這么寫當然沒什么毛病，甚至為了讓kotlin支持對接口Callback的SAM轉(zhuǎn)換，你還可以在接口前面增加一個fun修飾：

funinterfaceCallback{

funresponse()

}

但是對于Kotlin而言，本身函數(shù)類型是可以被實現(xiàn)的，也就是說我們可以使用函數(shù)類型替換函數(shù)式接口，讓子類去實現(xiàn)，代碼如下：

classAchieve:()-String{

overridefuninvoke():String{

return""

}

這種實現(xiàn)函數(shù)類型的類需要重寫的方法都是invoke()，方法返回值類型對應的就是函數(shù)類型的返回值類型。

這種寫法我在LeakCanary的源碼中就看到了應用，比如監(jiān)聽Fragment是否銷毀的類AndroidOFragmentDestroyWatcher：

在這里寫下我對這兩種方式優(yōu)缺點的比較：

1.函數(shù)類型相比較于接口去實現(xiàn)的優(yōu)點如下：

參數(shù)類型更加直觀

某個類實現(xiàn)了函數(shù)類型，能直觀的看到這個函數(shù)類型需要傳入的參數(shù)有哪些，是什么類型，返回值又是什么類型，而如果實現(xiàn)了一個接口，一般大家都習慣跳轉(zhuǎn)到接口定義的地方看接口方法的實現(xiàn)，所以這一點函數(shù)類型會更加方便些

檢索更方便

函數(shù)類型需要重寫的方法名一定叫invoke，所以如果我需要看下某個實現(xiàn)類對重寫方法的具體實現(xiàn)邏輯，直接在當前類中搜索invoke關鍵字定位到這個方法即可；而如果是一個接口接口，我得跳轉(zhuǎn)到接口的定義的地方看接口方法名是什么，才能去實現(xiàn)類中去搜索，所以在這點上函數(shù)類型會更加方便些

2.函數(shù)類型相比較于接口去實現(xiàn)的缺點如下：

函數(shù)類型語義性會比較差：

畢竟定義的接口名一般是和業(yè)務進行綁定的，能大概知道這個接口是干啥用的，更加清晰直觀，當然這個問題我們可以使用typealias解決，但就會失去上面參數(shù)類型更加直觀的優(yōu)點

多態(tài)性會比較差（自己編的，不知道合不合理）

比如如果定義的一個接口去實現(xiàn)，我們很容易實現(xiàn)下面這種功能：

funtest(achieve:Achieve){

if(achieveisCallback){

//實現(xiàn)某些邏輯

}

而如果使用函數(shù)類型去實現(xiàn)這種邏輯：

看起來是不是很奇怪，而且對于很多需要重寫的方法簽名都是相同的（方法參數(shù)和返回值都是相同的），根本無法實現(xiàn)這種功能，具體的看下面一點的描述。

無法實現(xiàn)多個相同的函數(shù)類型

業(yè)務場景中也存在實現(xiàn)多個接口，并且接口定義的方法參數(shù)和返回值類型都是相同的，比如下面：

funinterfaceCallback{

funresponse():String

funinterfaceCallback2{

funresponse2():String

classAchieve2:Callback,Callback2{

overridefunresponse():String{

return""

overridefunresponse2():String{

return""

}

如果使用函數(shù)類型根本無法實