接口與函數類型

業務開發中，經常會有實現一個函數式接口（即接口只有一個方法需要實現）的場景，大家應該都會不假思索的寫出如下代碼：

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

如果使用函數類型根本無法實現上面的這種多個接口實現的功能：

直接進行報錯。

總結

不管是實現函數類型還是接口，兩者都各有其優缺點，大家需要根據業務場景進行具體的選擇