一、receiver 參數(shù)類型對(duì) Go 方法的影響

要想為 receiver 參數(shù)選出合理的類型，我們先要了解不同的 receiver 參數(shù)類型會(huì)對(duì) Go 方法產(chǎn)生怎樣的影響。其實(shí)，Go 方法實(shí)質(zhì)上是以方法的 receiver 參數(shù)作為第一個(gè)參數(shù)的普通函數(shù)。

對(duì)于函數(shù)參數(shù)類型對(duì)函數(shù)的影響，我們是很熟悉的。那么我們能不能將方法等價(jià)轉(zhuǎn)換為對(duì)應(yīng)的函數(shù)，再通過分析 receiver 參數(shù)類型對(duì)函數(shù)的影響，從而間接得出它對(duì) Go 方法的影響呢？

基于這個(gè)思路。我們直接來看下面例子中的兩個(gè) Go 方法，以及它們等價(jià)轉(zhuǎn)換后的函數(shù)：

func (t T) M1() <=> F1(t T)
func (t *T) M2() <=> F2(t *T)

這個(gè)例子中有方法 M1 和 M2。M1 方法是 receiver 參數(shù)類型為 T 的一類方法的代表，而 M2 方法則代表了 receiver 參數(shù)類型為 *T 的另一類。下面我們分別來看看不同的 receiver 參數(shù)類型對(duì) M1 和 M2 的影響。

首先，當(dāng) receiver 參數(shù)的類型為 T 時(shí)：當(dāng)我們選擇以 T 作為 receiver 參數(shù)類型時(shí)，M1 方法等價(jià)轉(zhuǎn)換為 F1(t T)。我們知道，Go 函數(shù)的參數(shù)采用的是值拷貝傳遞，也就是說，F1 函數(shù)體中的 t 是 T 類型實(shí)例的一個(gè)副本。這樣，我們?cè)?nbsp;F1 函數(shù)的實(shí)現(xiàn)中對(duì)參數(shù) t 做任何修改，都只會(huì)影響副本，而不會(huì)影響到原 T 類型實(shí)例。

據(jù)此我們可以得出結(jié)論：當(dāng)我們的方法 M1 采用類型為 T 的 receiver 參數(shù)時(shí)，代表 T 類型實(shí)例的 receiver 參數(shù)以值傳遞方式傳遞到 M1 方法體中的，實(shí)際上是 T 類型實(shí)例的副本，M1 方法體中對(duì)副本的任何修改操作，都不會(huì)影響到原 T 類型實(shí)例。

第二，當(dāng) receiver 參數(shù)的類型為 *T 時(shí)：當(dāng)我們選擇以 *T 作為 receiver 參數(shù)類型時(shí)，M2 方法等價(jià)轉(zhuǎn)換為 F2(t *T)。同上面分析，我們傳遞給 F2 函數(shù)的 t 是 T 類型實(shí)例的地址，這樣 F2 函數(shù)體中對(duì)參數(shù) t 做的任何修改，都會(huì)反映到原 T 類型實(shí)例上。

據(jù)此我們也可以得出結(jié)論：當(dāng)我們的方法 M2 采用類型為 *T 的 receiver 參數(shù)時(shí)，代表 *T 類型實(shí)例的 receiver 參數(shù)以值傳遞方式傳遞到 M2 方法體中的，實(shí)際上是 T 類型實(shí)例的地址，M2 方法體通過該地址可以對(duì)原 T 類型實(shí)例進(jìn)行任何修改操作。

我們?cè)偻ㄟ^一個(gè)更直觀的例子，證明一下上面這個(gè)分析結(jié)果，看一下 Go 方法選擇不同的 receiver 類型對(duì)原類型實(shí)例的影響：

package main
  
type T struct {
    a int
}

func (t T) M1() {
    t.a = 10
}

func (t *T) M2() {
    t.a = 11
}

func main() {
    var t T
    println(t.a) // 0

    t.M1()
    println(t.a) // 0

    p := &t
    p.M2()
    println(t.a) // 11
}

在這個(gè)示例中，我們?yōu)榛愋?nbsp;T 定義了兩個(gè)方法 M1 和 M2，其中 M1 的 receiver 參數(shù)類型為 T，而 M2 的 receiver 參數(shù)類型為 *T。M1 和 M2 方法體都通過 receiver 參數(shù) t 對(duì) t 的字段 a 進(jìn)行了修改。

但運(yùn)行這個(gè)示例程序后，我們看到，方法 M1 由于使用了 T 作為 receiver 參數(shù)類型，它在方法體中修改的僅僅是 T 類型實(shí)例 t 的副本，原實(shí)例并沒有受到影響。因此 M1 調(diào)用后，輸出 t.a 的值仍為 0。

而方法 M2 呢，由于使用了 *T 作為 receiver 參數(shù)類型，它在方法體中通過 t 修改的是實(shí)例本身，因此 M2 調(diào)用后，t.a 的值變?yōu)榱?11，這些輸出結(jié)果與我們前面的分析是一致的。

二、選擇 receiver 參數(shù)類型原則

2.1 選擇 receiver 參數(shù)類型的第一個(gè)原則

基于上面的影響分析，我們可以得到選擇 receiver 參數(shù)類型的第一個(gè)原則：如果 Go 方法要把對(duì) receiver 參數(shù)代表的類型實(shí)例的修改，反映到原類型實(shí)例上，那么我們應(yīng)該選擇 *T 作為 receiver 參數(shù)的類型。

可能會(huì)有個(gè)疑問：如果我們選擇了 *T 作為 Go 方法 receiver 參數(shù)的類型，那么我們是不是只能通過 *T 類型變量調(diào)用該方法，而不能通過 T 類型變量調(diào)用了呢？我們改造上面例子看一下：

  type T struct {
      a int
  }
  
  func (t T) M1() {
      t.a = 10
  }
 
 func (t *T) M2() {
     t.a = 11
 }
 
 func main() {
     var t1 T
     println(t1.a) // 0
     t1.M1()
     println(t1.a) // 0
     t1.M2()
     println(t1.a) // 11
 
     var t2 = &T{}
     println(t2.a) // 0
     t2.M1()
     println(t2.a) // 0
     t2.M2()
     println(t2.a) // 11
 }

我們先來看看類型為 T 的實(shí)例 t1。我們看到它不僅可以調(diào)用 receiver 參數(shù)類型為 T 的方法 M1，它還可以直接調(diào)用 receiver 參數(shù)類型為 *T 的方法 M2，并且調(diào)用完 M2 方法后，t1.a 的值被修改為 11 了。

其實(shí)，T 類型的實(shí)例 t1 之所以可以調(diào)用 receiver 參數(shù)類型為 *T 的方法 M2，都是 Go 編譯器在背后自動(dòng)進(jìn)行轉(zhuǎn)換的結(jié)果?；蛘哒f，t1.M2() 這種用法是 Go 提供的“語法糖”：Go 判斷 t1 的類型為 T，也就是與方法 M2 的 receiver 參數(shù)類型 *T 不一致后，會(huì)自動(dòng)將 t1.M2() 轉(zhuǎn)換為 (&t1).M2()。

同理，類型為 *T 的實(shí)例 t2，它不僅可以調(diào)用 receiver 參數(shù)類型為 *T 的方法 M2，還可以調(diào)用 receiver 參數(shù)類型為 T 的方法 M1，這同樣是因?yàn)?Go 編譯器在背后做了轉(zhuǎn)換。也就是，Go 判斷 t2 的類型為 *T，與方法 M1 的 receiver 參數(shù)類型 T 不一致，就會(huì)自動(dòng)將 t2.M1() 轉(zhuǎn)換為 (*t2).M1()。

通過這個(gè)實(shí)例，我們知道了這樣一個(gè)結(jié)論：無論是 T 類型實(shí)例，還是 *T 類型實(shí)例，都既可以調(diào)用 receiver 為 T 類型的方法，也可以調(diào)用 receiver 為 *T 類型的方法。這樣，我們?cè)跒榉椒ㄟx擇 receiver 參數(shù)的類型的時(shí)候，就不需要擔(dān)心這個(gè)方法不能被與 receiver 參數(shù)類型不一致的類型實(shí)例調(diào)用了。

2.2 選擇 receiver 參數(shù)類型的第二個(gè)原則

前面我們第一個(gè)原則說的是，當(dāng)我們要在方法中對(duì) receiver 參數(shù)代表的類型實(shí)例進(jìn)行修改，那我們要為 receiver 參數(shù)選擇 *T 類型，但是如果我們不需要在方法中對(duì)類型實(shí)例進(jìn)行修改呢？這個(gè)時(shí)候我們是為 receiver 參數(shù)選擇 T 類型還是 *T 類型呢？

這也得分情況。一般情況下，我們通常會(huì)為 receiver 參數(shù)選擇 T 類型，因?yàn)檫@樣可以縮窄外部修改類型實(shí)例內(nèi)部狀態(tài)的“接觸面”，也就是盡量少暴露可以修改類型內(nèi)部狀態(tài)的方法。

不過也有一個(gè)例外需要你特別注意。考慮到 Go 方法調(diào)用時(shí)，receiver 參數(shù)是以值拷貝的形式傳入方法中的。那么，如果 receiver 參數(shù)類型的 size 較大，以值拷貝形式傳入就會(huì)導(dǎo)致較大的性能開銷，這時(shí)我們選擇 *T 作為 receiver 類型可能更好些。

以上這些可以作為我們選擇 receiver 參數(shù)類型的第二個(gè)原則。

三、方法集合（Method Set）

3.1 引入

我們先通過一個(gè)示例，直觀了解一下為什么要有方法集合，它主要用來解決什么問題：

type Interface interface {
    M1()
    M2()
}

type T struct{}

func (t T) M1()  {}
func (t *T) M2() {}

func main() {
    var t T
    var pt *T
    var i Interface

    i = pt
    i = t // cannot use t (type T) as type Interface in assignment: T does not implement Interface (M2 method has pointer receiver)
}

在這個(gè)例子中，我們定義了一個(gè)接口類型 Interface 以及一個(gè)自定義類型 T。Interface 接口類型包含了兩個(gè)方法 M1 和 M2，代碼中還定義了基類型為 T 的兩個(gè)方法 M1 和 M2，但它們的 receiver 參數(shù)類型不同，一個(gè)為 T，另一個(gè)為 *T。在 main 函數(shù)中，我們分別將 T 類型實(shí)例 t 和 *T 類型實(shí)例 pt 賦值給 Interface 類型變量 i。

運(yùn)行一下這個(gè)示例程序，我們?cè)?nbsp;i = t 這一行會(huì)得到 Go 編譯器的錯(cuò)誤提示，Go 編譯器提示我們：T 沒有實(shí)現(xiàn) Interface 類型方法列表中的 M2，因此類型 T 的實(shí)例 t 不能賦值給 Interface 變量。

可是，為什么呢？為什么 *T 類型的 pt 可以被正常賦值給 Interface 類型變量 i，而 T 類型的 t 就不行呢？如果說 T 類型是因?yàn)橹粚?shí)現(xiàn)了 M1 方法，未實(shí)現(xiàn) M2 方法而不滿足 Interface 類型的要求，那么 *T 類型也只是實(shí)現(xiàn)了 M2 方法，并沒有實(shí)現(xiàn) M1 方法??？

有些事情并不是表面看起來這個(gè)樣子的。了解方法集合后，這個(gè)問題就迎刃而解了。同時(shí)，方法集合也是用來判斷一個(gè)類型是否實(shí)現(xiàn)了某接口類型的唯一手段，可以說，“方法集合決定了接口實(shí)現(xiàn)”。

3.2 類型的方法集合

Go 中任何一個(gè)類型都有屬于自己的方法集合，或者說方法集合是 Go 類型的一個(gè)“屬性”。但不是所有類型都有自巴基斯坦的方法呀，比如 int 類型就沒有。所以，對(duì)于沒有定義方法的 Go 類型，我們稱其擁有空方法集合。

接口類型相對(duì)特殊，它只會(huì)列出代表接口的方法列表，不會(huì)具體定義某個(gè)方法，它的方法集合就是它的方法列表中的所有方法，我們可以一目了然地看到。

為了方便查看一個(gè)非接口類型的方法集合，這里提供了一個(gè)函數(shù) dumpMethodSet，用于輸出一個(gè)非接口類型的方法集合：

func dumpMethodSet(i interface{}) {
    dynTyp := reflect.TypeOf(i)

    if dynTyp == nil {
        fmt.Printf("there is no dynamic type\n")
        return
    }

    n := dynTyp.NumMethod()
    if n == 0 {
        fmt.Printf("%s's method set is empty!\n", dynTyp)
        return
    }

    fmt.Printf("%s's method set:\n", dynTyp)
    for j := 0; j < n; j++ {
        fmt.Println("-", dynTyp.Method(j).Name)
    }
    fmt.Printf("\n")
}

下面我們利用這個(gè)函數(shù)，試著輸出一下 Go 原生類型以及自定義類型的方法集合，看下面代碼：

type T struct{}

func (T) M1() {}
func (T) M2() {}

func (*T) M3() {}
func (*T) M4() {}

func main() {
    var n int
    dumpMethodSet(n)
    dumpMethodSet(&n)

    var t T
    dumpMethodSet(t)
    dumpMethodSet(&t)
}

運(yùn)行這段代碼，我們得到如下結(jié)果：

int's method set is empty!
*int's method set is empty!
main.T's method set:
- M1
- M2
*main.T's method set:
- M1
- M2
- M3
- M4

我們看到以 int、*int 為代表的 Go 原生類型由于沒有定義方法，所以它們的方法集合都是空的。自定義類型 T 定義了方法 M1 和 M2，因此它的方法集合包含了 M1 和 M2，也符合我們預(yù)期。但 *T 的方法集合中除了預(yù)期的 M3 和 M4 之外，居然還包含了類型 T 的方法 M1 和 M2！

不過，這里程序的輸出并沒有錯(cuò)誤。

這是因?yàn)?，Go 語言規(guī)定，*T 類型的方法集合包含所有以 *T 為 receiver 參數(shù)類型的方法，以及所有以 T 為 receiver 參數(shù)類型的方法。這就是這個(gè)示例中為何 *T 類型的方法集合包含四個(gè)方法的原因。

這個(gè)時(shí)候，你是不是也找到了前面那個(gè)示例中為何 i = pt 沒有報(bào)編譯錯(cuò)誤的原因了呢？我們同樣可以使用 dumpMethodSet 工具函數(shù)，輸出一下那個(gè)例子中 pt 與 t 各自所屬類型的方法集合：

type Interface interface {
    M1()
    M2()
}

type T struct{}

func (t T) M1()  {}
func (t *T) M2() {}

func main() {
    var t T
    var pt *T
    dumpMethodSet(t)
    dumpMethodSet(pt)
}

運(yùn)行上述代碼，我們得到如下結(jié)果：

main.T's method set:
- M1
*main.T's method set:
- M1
- M2

通過這個(gè)輸出結(jié)果，我們可以一目了然地看到 T、*T 各自的方法集合。

我們看到，T 類型的方法集合中只包含 M1，沒有 Interface 類型方法集合中的 M2 方法，這就是 Go 編譯器認(rèn)為變量 t 不能賦值給 Interface 類型變量的原因

在輸出的結(jié)果中，我們還看到 *T 類型的方法集合除了包含它自身定義的 M2 方法外，還包含了 T 類型定義的 M1 方法，*T 的方法集合與 Interface 接口類型的方法集合是一樣的，因此 pt 可以被賦值給 Interface 接口類型的變量 i。

到這里，我們已經(jīng)知道了所謂的方法集合決定接口實(shí)現(xiàn)的含義就是：如果某類型 T 的方法集合與某接口類型的方法集合相同，或者類型 T 的方法集合是接口類型 I 方法集合的超集，那么我們就說這個(gè)類型 T 實(shí)現(xiàn)了接口 I?；蛘哒f，方法集合這個(gè)概念在 Go 語言中的主要用途，就是用來判斷某個(gè)類型是否實(shí)現(xiàn)了某個(gè)接口。

四、選擇 receiver 參數(shù)類型的第三個(gè)原則

理解了方法集合后，我們?cè)倮斫獾谌齻€(gè)原則的內(nèi)容就不難了。這個(gè)原則的選擇依據(jù)就是 T 類型是否需要實(shí)現(xiàn)某個(gè)接口，也就是是否存在將 T 類型的變量賦值給某接口類型變量的情況。

理解了方法集合后，我們?cè)倮斫獾谌齻€(gè)原則的內(nèi)容就不難了。這個(gè)原則的選擇依據(jù)就是 T 類型是否需要實(shí)現(xiàn)某個(gè)接口，也就是是否存在將 T 類型的變量賦值給某接口類型變量的情況。

如果 T 類型需要實(shí)現(xiàn)某個(gè)接口，那我們就要使用 T 作為 receiver 參數(shù)的類型，來滿足接口類型方法集合中的所有方法。

如果 T 不需要實(shí)現(xiàn)某一接口，但 *T 需要實(shí)現(xiàn)該接口，那么根據(jù)方法集合概念，*T 的方法集合是包含 T 的方法集合的，這樣我們?cè)诖_定 Go 方法的 receiver 的類型時(shí)，參考原則一和原則二就可以了。

如果說前面的兩個(gè)原則更多聚焦于類型內(nèi)部，從單個(gè)方法的實(shí)現(xiàn)層面考慮，那么這第三個(gè)原則則是更多從全局的設(shè)計(jì)層面考慮，聚焦于這個(gè)類型與接口類型間的耦合關(guān)系。

五、小結(jié)

在實(shí)際進(jìn)行 Go 方法設(shè)計(jì)時(shí)，我們首先應(yīng)該考慮的是原則三，即 T 類型是否要實(shí)現(xiàn)某一接口。如果 T 類型需要實(shí)現(xiàn)某一接口的全部方法，那么我們就需要使用 T 作為 receiver 參數(shù)的類型來滿足接口類型方法集合中的所有方法。

如果 T 類型不需要實(shí)現(xiàn)某一接口，那么我們就可以參考原則一和原則二來為 receiver 參數(shù)選擇類型了。也就是，如果 Go 方法要把對(duì) receiver 參數(shù)所代表的類型實(shí)例的修改反映到原類型實(shí)例上，那么我們應(yīng)該選擇 *T 作為 receiver 參數(shù)的類型。否則通常我們會(huì)為 receiver 參數(shù)選擇 T 類型，這樣可以減少外部修改類型實(shí)例內(nèi)部狀態(tài)的“渠道”。除非 receiver 參數(shù)類型的 size 較大，考慮到傳值的較大性能開銷，選擇 *T 作為 receiver 類型可能更適合。

方法集合在 Go 語言中的主要用途就是判斷某個(gè)類型是否實(shí)現(xiàn)了某個(gè)接口。方法集合像“膠水”一樣，將自定義類型與接口隱式地“粘結(jié)”在一起

以上就是淺析Go語言中的方法集合與選擇receiver類型的詳細(xì)內(nèi)容，更多關(guān)于Go方法集合與receiver的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！