Go類型嵌入介紹和使用類型嵌入模擬實現“繼承”

来源:https://www.cnblogs.com/taoxiaoxin/archive/2023/11/05/17810524.html
-Advertisement-
Play Games

Go類型嵌入介紹和使用類型嵌入模擬實現“繼承” 目錄Go類型嵌入介紹和使用類型嵌入模擬實現“繼承”一、獨立的自定義類型二、繼承三、類型嵌入3.1 什麼是類型嵌入四、介面類型的類型嵌入4.1 介面類型的類型嵌入介紹4.2 一個小案例五、結構體類型的類型嵌入5.1 結構體類型的類型嵌入介紹5.2 小案例 ...


Go類型嵌入介紹和使用類型嵌入模擬實現“繼承”

目錄

一、獨立的自定義類型

什麼是獨立的自定義類型呢？就是這個類型的所有方法都是自己顯式實現的。

我們舉個例子，自定義類型 T 有兩個方法 M1 和 M2，如果 T 是一個獨立的自定義類型，那我們在聲明類型 T 的 Go 包源碼文件中一定可以找到其所有方法的實現代碼，比如：

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

難道還有某種自定義類型的方法不是自己顯式實現的嗎？當涉及到 Go 語言中的自定義類型時，有一種方法可以不需要顯式地實現方法，即：讓某個自定義類型“繼承”其他類型的方法實現。

二、繼承

Go 語言從設計伊始，就決定不支持經典面向對象的編程範式與語法元素，所以我們這裡只是借用了“繼承”這個辭彙而已，說是“繼承”，實則依舊是一種組合的思想。

這種“繼承”是通過 Go 語言的類型嵌入（Type Embedding）來實現的。

三、類型嵌入

3.1 什麼是類型嵌入

類型嵌入指的就是在一個類型的定義中嵌入了其他類型。Go 語言支持兩種類型嵌入，分別是介面類型的類型嵌入和結構體類型的類型嵌入。

四、介面類型的類型嵌入

4.1 介面類型的類型嵌入介紹

介面類型的類型嵌入是指在一個介面類型的定義中嵌入其他介面類型，從而使介面類型包含了嵌入介面中定義的方法。這允許一個介面類型繼承另一個介面類型的方法集，以擴展其功能。

總結介面類型的類型嵌入的關鍵點：

  1. 嵌入介面類型：介面類型可以嵌入其他介面類型，將其方法集合併到當前介面中。
  2. 繼承方法集：通過嵌入，介面類型可以繼承嵌入介面中的方法，使得當前介面也具有這些方法。
  3. 實現多態：通過介面類型的類型嵌入，可以實現多態，使不同類型的對象可以被統一地處理，提高代碼的靈活性。

這種機制使得Go語言的介面更加靈活和可擴展，允許將不同的介面組合在一起，以創建更複雜的介面，從而促進了代碼的重用和可維護性。

4.2 一個小案例

接著，我們用一個案例，直觀地瞭解一下什麼是介面類型的類型嵌入。我們知道，介面類型聲明瞭由一個方法集合代表的介面，比如下麵介面類型 E：

type E interface {
    M1()
    M2()
}

這個介面類型 E 的方法集合，包含兩個方法，分別是 M1 和 M2，它們組成了 E 這個介面類型所代表的介面。如果某個類型實現了方法 M1 和 M2，我們就說這個類型實現了 E 所代表的介面。

此時，我們再定義另外一個介面類型 I，它的方法集合中包含了三個方法 M1、M2 和 M3，如下麵代碼：

type I interface {
    M1()
    M2()
    M3()
}

我們看到介面類型 I 方法集合中的 M1 和 M2，與介面類型 E 的方法集合中的方法完全相同。在這種情況下，我們可以用介面類型 E 替代上面介面類型 I 定義中 M1 和 M2，如下麵代碼：

type I interface {
    E
    M3()
}

像這種在一個介面類型（I）定義中，嵌入另外一個介面類型（E）的方式，就是我們說的介面類型的類型嵌入。

而且，這個帶有類型嵌入的介面類型 I 的定義與上面那個包含 M1、M2 和 M3 的介面類型 I 的定義，是等價的。因此，我們可以得到一個結論，這種介面類型嵌入的語義就是新介面類型（如介面類型 I）將嵌入的介面類型（如介面類型 E）的方法集合，併入到自己的方法集合中。

其實，使用類型嵌入方式定義介面類型也是 Go 組合設計哲學的一種體現。

按 Go 語言慣例，Go 中的介面類型中只包含少量方法，並且常常只是一個方法。通過在介面類型中嵌入其他介面類型可以實現介面的組合，這也是 Go 語言中基於已有介面類型構建新介面類型的慣用法。

按 Go 語言慣例，Go 中的介面類型中只包含少量方法，並且常常只是一個方法。通過在介面類型中嵌入其他介面類型可以實現介面的組合，這也是 Go 語言中基於已有介面類型構建新介面類型的慣用法。

我們在 Go 標準庫中可以看到很多這種組合方式的應用，最常見的莫過於 io 包中一系列介面的定義了。比如，io 包的 ReadWriter、ReadWriteCloser 等介面類型就是通過嵌入 Reader、Writer 或 Closer 三個基本的介面類型組合而成的。下麵是僅包含單一方法的 io 包 Reader、Writer 和 Closer 的定義：

// $GOROOT/src/io/io.go

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type Closer interface {
    Close() error
}

下麵的 io 包的 ReadWriter、ReadWriteCloser 等介面類型，通過嵌入上面基本介面類型組合而形成：

type ReadWriter interface {
    Reader
    Writer
}

type ReadCloser interface {
    Reader
    Closer
}

type WriteCloser interface {
    Writer
    Closer
}

type ReadWriteCloser interface {
    Reader
    Writer
    Closer
}

不過，這種通過嵌入其他介面類型來創建新介面類型的方式，在 Go 1.14 版本之前是有約束的：如果新介面類型嵌入了多個介面類型，這些嵌入的介面類型的方法集合不能有交集，同時嵌入的介面類型的方法集合中的方法名字，也不能與新介面中的其他方法同名。比如我們用 Go 1.12.7 版本運行下麵例子，Go 編譯器就會報錯：

type Interface1 interface {
    M1()
}

type Interface2 interface {
    M1()
    M2()
}

type Interface3 interface {
    Interface1
    Interface2 // Error: duplicate method M1
}

type Interface4 interface {
    Interface2
    M2() // Error: duplicate method M2
}

func main() {
}

我們具體看一下例子中的兩個編譯報錯：第一個是因為 Interface3 中嵌入的兩個介面類型 Interface1 和 Interface2 的方法集合有交集，交集是方法 M1；第二個報錯是因為 Interface4 類型中的方法 M2 與嵌入的介面類型 Interface2 的方法 M2 重名。

但自 Go 1.14 版本開始，Go 語言去除了這些約束，我們使用 Go 最新版本運行上面這個示例就不會得到編譯錯誤了。

介面類型的類型嵌入比較簡單，我們只要把握好它的語義，也就是“方法集合併入”就可以了。

五、結構體類型的類型嵌入

5.1 結構體類型的類型嵌入介紹

結構體類型的類型嵌入是一種特殊的結構體定義方式，其中結構體的欄位名可以直接使用類型名、類型的指針類型名或介面類型名，代表欄位的名字和類型。以下是結構體類型的類型嵌入的關鍵點：

  1. 欄位名和類型合二為一：在結構體類型的類型嵌入中，欄位名和類型名合併成一個標識符，既代表了欄位的名字又代表了欄位的類型。這使得欄位名與類型名保持一致，簡化了結構體定義。
  2. 嵌入欄位：這種方式被稱為嵌入欄位（Embedded Field），其中嵌入欄位的類型可以是自定義類型、結構體類型的指針類型，或介面類型。
  3. 訪問嵌入欄位：可以通過結構體變數來訪問嵌入欄位的欄位和方法，無需使用欄位名，因為欄位名已經隱含在類型中。
  4. 欄位名與類型名一致：嵌入欄位的欄位名與類型名一致，這種一致性使得代碼更加清晰和直觀。
  5. 類型組合：通過嵌入欄位，可以將不同類型的功能組合在一個結構體中，形成更複雜的數據結構，提高代碼的可維護性和擴展性。

5.2 小案例

通常，結構體都是類似下麵這樣的：

type S struct {
    A int
    b string
    c T
    p *P
    _ [10]int8
    F func()
}

結構體類型 S 中的每個欄位（field）都有唯一的名字與對應的類型，即便是使用空標識符占位的欄位，它的類型也是明確的，但這還不是 Go 結構體類型的“完全體”。Go 結構體類型定義還有另外一種形式，那就是帶有嵌入欄位（Embedded Field）的結構體定義。我們看下麵這個例子：

type T1 int
type t2 struct{
    n int
    m int
}

type I interface {
    M1()
}

type S1 struct {
    T1
    *t2
    I            
    a int
    b string
}

我們看到，結構體 S1 定義中有三個“非常規形式”的標識符，分別是 T1、t2 和 I，這三個標識符究竟代表的是什麼呢？是欄位名還是欄位的類型呢？這裡我直接告訴你答案：它們既代表欄位的名字，也代表欄位的類型。我們分別以這三個標識符為例，說明一下它們的具體含義：

  • 標識符 T1 表示欄位名為 T1，它的類型為自定義類型 T1；
  • 標識符 t2 表示欄位名為 t2，它的類型為自定義結構體類型 t2 的指針類型；
  • 標識符 I 表示欄位名為 I，它的類型為介面類型 I。

這種以某個類型名、類型的指針類型名或介面類型名，直接作為結構體欄位的方式就叫做結構體的類型嵌入，這些欄位也被叫做嵌入欄位（Embedded Field）。

那麼，嵌入欄位怎麼用呢？它跟普通結構體欄位有啥不同呢？我們結合具體的例子，簡單說一下嵌入欄位的用法：

type MyInt int

func (n *MyInt) Add(m int) {
    *n = *n + MyInt(m)
}

type t struct {
    a int
    b int
}

type S struct {
    *MyInt
    t
    io.Reader
    s string
    n int
}

func main() {
    m := MyInt(17)
    r := strings.NewReader("hello, go")
    s := S{
        MyInt: &m,
        t: t{
            a: 1,
            b: 2,
        },
        Reader: r,
        s:      "demo",
    }

    var sl = make([]byte, len("hello, go"))
    s.Reader.Read(sl)
    fmt.Println(string(sl)) // hello, go
    s.MyInt.Add(5)
    fmt.Println(*(s.MyInt)) // 22
}

在分析這段代碼之前，我們要先明確一點，那就是嵌入欄位的可見性與嵌入欄位的類型的可見性是一致的。如果嵌入類型的名字是首字母大寫的，那麼也就說明這個嵌入欄位是可導出的。

現在我們來看這個例子。

首先，這個例子中的結構體類型 S 使用了類型嵌入方式進行定義，它有三個嵌入欄位 MyInt、t 和 Reader。這裡，你可能會問，為什麼第三個嵌入欄位的名字為 Reader 而不是 io.Reader？這是因為，Go 語言規定如果結構體使用從其他包導入的類型作為嵌入欄位，比如 pkg.T，那麼這個嵌入欄位的欄位名就是 T，代表的類型為 pkg.T。

接下來，我們再來看結構體類型 S 的變數的初始化。我們使用 field:value 方式對 S 類型的變數 s 的各個欄位進行初始化。和普通的欄位一樣，初始化嵌入欄位時，我們可以直接用嵌入欄位名作為 field。

而且，通過變數 s 使用這些嵌入欄位時，我們也可以像普通欄位那樣直接用 變數s + 欄位選擇符 + 嵌入欄位的名字，比如 s.Reader。我們還可以通過這種方式調用嵌入欄位的方法，比如 s.Reader.Read 和 s.MyInt.Add。

這樣看起來，嵌入欄位的用法和普通欄位沒啥不同呀？也不完全是，Go 還是對嵌入欄位有一些約束的。比如，和 Go 方法的 receiver 的基類型一樣，嵌入欄位類型的底層類型不能為指針類型。而且，嵌入欄位的名字在結構體定義也必須是唯一的，這也意味這如果兩個類型的名字相同，它們無法同時作為嵌入欄位放到同一個結構體定義中。不過，這些約束你瞭解一下就可以了，一旦違反，Go 編譯器會提示你的。

六、“實現繼承”的原理

將上面例子代碼做一下細微改動，我這裡只列了變化部分的代碼：

var sl = make([]byte, len("hello, go"))
s.Read(sl) 
fmt.Println(string(sl))
s.Add(5) 
fmt.Println(*(s.MyInt))

這段代碼中，類型 S 也沒有定義 Read 方法和 Add 方法，但是這段程式不但沒有引發編譯器報錯，還可以正常運行並輸出與前面例子相同的結果！

這段代碼似乎在告訴我們：Read 方法與 Add 方法就是類型 S 方法集合中的方法。但是，這裡類型 S 明明沒有顯式實現這兩個方法呀，它是從哪裡得到這兩個方法的實現的呢？

其實，這兩個方法就來自結構體類型 S 的兩個嵌入欄位 Reader 和 MyInt。結構體類型 S “繼承”了 Reader 欄位的方法 Read 的實現，也“繼承”了 *MyInt 的 Add 方法的實現。註意，我這裡的“繼承”用了引號，說明這並不是真正的繼承，它只是 Go 語言的一種“障眼法”。

這種“障眼法”的工作機制是這樣的，當我們通過結構體類型 S 的變數 s 調用 Read 方法時，Go 發現結構體類型 S 自身並沒有定義 Read 方法，於是 Go 會查看 S 的嵌入欄位對應的類型是否定義了 Read 方法。這個時候，Reader 欄位就被找了出來，之後 s.Read 的調用就被轉換為 s.Reader.Read 調用。

這樣一來，嵌入欄位 Reader 的 Read 方法就被提升為 S 的方法，放入了類型 S 的方法集合。同理 *MyInt 的 Add 方法也被提升為 S 的方法而放入 S 的方法集合。從外部來看，這種嵌入欄位的方法的提升就給了我們一種結構體類型 S“繼承”了 io.Reader 類型 Read 方法的實現，以及 *MyInt 類型 Add 方法的實現的錯覺。

到這裡，我們就清楚了，嵌入欄位的使用的確可以幫我們在 Go 中實現方法的“繼承”。

在文章開頭，類型嵌入這種看似“繼承”的機制，實際上是一種組合的思想。更具體點，它是一種組合中的代理（delegate）模式，如下圖所示：

WechatIMG247

我們看到，S 只是一個代理（delegate），對外它提供了它可以代理的所有方法，如例子中的 Read 和 Add 方法。當外界發起對 S 的 Read 方法的調用後，S 將該調用委派給它內部的 Reader 實例來實際執行 Read 方法。

七、類型嵌入與方法集合

在前面，介面類型的類型嵌入時我們提到介面類型的類型嵌入的本質，就是嵌入類型的方法集合併入到新介面類型的方法集合中，並且，介面類型只能嵌入介面類型。而結構體類型對嵌入類型的要求就比較寬泛了，可以是任意自定義類型或介面類型。

下麵我們就分別看看，在這兩種情況下，結構體類型的方法集合會有怎樣的變化。我們依舊藉助上一講中的 dumpMethodSet 函數來輸出各個類型的方法集合，這裡，我就不在例子中重覆列出 dumpMethodSet 的代碼了。

7.1 結構體類型中嵌入介面類型

在結構體類型中嵌入介面類型後，結構體類型的方法集合會發生什麼變化呢？我們通過下麵這個例子來看一下：

type I interface {
    M1()
    M2()
}

type T struct {
    I
}

func (T) M3() {}

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

運行這個示例，我們會得到以下結果：

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

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

我們可以看到，原本結構體類型 T 只帶有一個方法 M3，但在嵌入介面類型 I 後，結構體類型 T 的方法集合中又併入了介面類型 I 的方法集合。並且，由於 *T 類型方法集合包括 T 類型的方法集合，因此無論是類型 T 還是類型 *T，它們的方法集合都包含 M1、M2 和 M3。於是我們可以得出一個結論：結構體類型的方法集合，包含嵌入的介面類型的方法集合。

不過有一種情況，你要註意一下，那就是當結構體嵌入的多個介面類型的方法集合存在交集時，你要小心編譯器可能會出現的錯誤提示。

雖然Go 1.14 版本解決了嵌入介面類型的方法集合有交集的情況，但那僅限於介面類型中嵌入介面類型，這裡我們說的是在結構體類型中嵌入方法集合有交集的介面類型。

根據我們前面講的，嵌入了其他類型的結構體類型本身是一個代理，在調用其實例所代理的方法時，Go 會首先查看結構體自身是否實現了該方法。

如果實現了，Go 就會優先使用結構體自己實現的方法。如果沒有實現，那麼 Go 就會查找結構體中的嵌入欄位的方法集合中，是否包含了這個方法。如果多個嵌入欄位的方法集合中都包含這個方法，那麼我們就說方法集合存在交集。這個時候，Go 編譯器就會因無法確定究竟使用哪個方法而報錯，下麵的這個例子就演示了這種情況：

  type E1 interface {
      M1()
      M2()
      M3()
  }
  
  type E2 interface {
     M1()
     M2()
     M4()
 }
 
 type T struct {
     E1
     E2
 }
 
 func main() {
     t := T{}
     t.M1()
     t.M2()
 }

運行這個例子，我們會得到：

main.go:22:3: ambiguous selector t.M1
main.go:23:3: ambiguous selector t.M2

我們看到，Go 編譯器給出了錯誤提示，表示在調用 t.M1 和 t.M2 時，編譯器都出現了分歧。在這個例子中，結構體類型 T 嵌入的兩個介面類型 E1 和 E2 的方法集合存在交集，都包含 M1 和 M2，而結構體類型 T 自身呢，又沒有實現 M1 和 M2，所以編譯器會因無法做出選擇而報錯。

那怎麼解決這個問題呢？其實有兩種解決方案。一是，我們可以消除 E1 和 E2 方法集合存在交集的情況。二是為 T 增加 M1 和 M2 方法的實現，這樣的話，編譯器便會直接選擇 T 自己實現的 M1 和 M2，不會陷入兩難境地。比如，下麵的例子演示的就是 T 增加了 M1 和 M2 方法實現的情況：

... ...
type T struct {
    E1
    E2
}

func (T) M1() { println("T's M1") }
func (T) M2() { println("T's M2") }

func main() {
    t := T{}
    t.M1() // T's M1
    t.M2() // T's M2
}

結構體類型嵌入介面類型在日常編碼中有一個妙用，就是可以簡化單元測試的編寫。由於嵌入某介面類型的結構體類型的方法集合包含了這個介面類型的方法集合，這就意味著，這個結構體類型也是它嵌入的介面類型的一個實現。即便結構體類型自身並沒有實現這個介面類型的任意一個方法，也沒有關係。我們來看一個直觀的例子：

package employee
  
type Result struct {
    Count int
}

func (r Result) Int() int { return r.Count }

type Rows []struct{}

type Stmt interface {
    Close() error
    NumInput() int
    Exec(stmt string, args ...string) (Result, error)
    Query(args []string) (Rows, error)
}

// 返回男性員工總數
func MaleCount(s Stmt) (int, error) {
    result, err := s.Exec("select count(*) from employee_tab where gender=?", "1")
    if err != nil {
        return 0, err
    }

    return result.Int(), nil
}

在這個例子中，我們有一個 employee 包，這個包中的方法 MaleCount，通過傳入的 Stmt 介面的實現從資料庫獲取男性員工的數量。

現在我們的任務是要對 MaleCount 方法編寫單元測試代碼。對於這種依賴外部資料庫操作的方法，我們的慣例是使用“偽對象（fake object）”來冒充真實的 Stmt 介面實現。

不過現在有一個問題，那就是 Stmt 介面類型的方法集合中有四個方法，而 MaleCount 函數只使用了 Stmt 介面的一個方法 Exec。如果我們針對每個測試用例所用的偽對象都實現這四個方法，那麼這個工作量有些大。

那麼這個時候，我們怎樣快速建立偽對象呢？結構體類型嵌入介面類型便可以幫助我們，下麵是我們的解決方案：

package employee
  
import "testing"

type fakeStmtForMaleCount struct {
    Stmt
}

func (fakeStmtForMaleCount) Exec(stmt string, args ...string) (Result, error) {
    return Result{Count: 5}, nil
}

func TestEmployeeMaleCount(t *testing.T) {
    f := fakeStmtForMaleCount{}
    c, _ := MaleCount(f)
    if c != 5 {
        t.Errorf("want: %d, actual: %d", 5, c)
        return
    }
}

我們為 TestEmployeeMaleCount 測試用例建立了一個 fakeStmtForMaleCount 的偽對象類型，然後在這個類型中嵌入了 Stmt 介面類型。這樣 fakeStmtForMaleCount 就實現了 Stmt 介面，我們也實現了快速建立偽對象的目的。接下來我們只需要為 fakeStmtForMaleCount 實現 MaleCount 所需的 Exec 方法，就可以滿足這個測試的要求了。

7.2 結構體類型中嵌入結構體類型

在前面結構體類型中嵌入結構體類型，為 Gopher 們提供了一種“實現繼承”的手段，外部的結構體類型 T 可以“繼承”嵌入的結構體類型的所有方法的實現。並且，無論是 T 類型的變數實例還是 *T 類型變數實例，都可以調用所有“繼承”的方法。但這種情況下，帶有嵌入類型的新類型究竟“繼承”了哪些方法，我們還要通過下麵這個具體的示例來看一下。

type T1 struct{}

func (T1) T1M1()   { println("T1's M1") }
func (*T1) PT1M2() { println("PT1's M2") }

type T2 struct{}

func (T2) T2M1()   { println("T2's M1") }
func (*T2) PT2M2() { println("PT2's M2") }

type T struct {
    T1
    *T2
}

func main() {
    t := T{
        T1: T1{},
        T2: &T2{},
    }

    dumpMethodSet(t)
    dumpMethodSet(&t)
}

在這個例子中，結構體類型 T 有兩個嵌入欄位，分別是 T1 和 *T2，根據上一講中我們對結構體的方法集合的講解，我們知道 T1 與 *T1、T2 與 *T2 的方法集合是不同的：

  • T1 的方法集合包含：T1M1；
  • *T1 的方法集合包含：T1M1、PT1M2；
  • T2 的方法集合包含：T2M1；
  • *T2 的方法集合包含：T2M1、PT2M2。

它們作為嵌入欄位嵌入到 T 中後，對 T 和 *T 的方法集合的影響也是不同的。我們運行一下這個示例，看一下輸出結果：

main.T's method set:
- PT2M2
- T1M1
- T2M1

*main.T's method set:
- PT1M2
- PT2M2
- T1M1
- T2M1

通過輸出結果，我們看到了 T 和 *T 類型的方法集合果然有差別的：

  • 類型 T 的方法集合 = T1 的方法集合 + *T2 的方法集合
  • 類型 *T 的方法集合 = *T1 的方法集合 + *T2 的方法集合

這裡，我們尤其要註意 *T 類型的方法集合，它包含的可不是 T1 類型的方法集合，而是 *T1 類型的方法集合。這和結構體指針類型的方法集合包含結構體類型方法集合，是一個道理。

到這裡，基於類型嵌入“繼承”方法實現的原理，我們基本都清楚了。但不知道你會不會還有一點疑惑：只有通過類型嵌入才能實現方法“繼承”嗎？如果我使用類型聲明語法基於一個已有類型 T 定義一個新類型 NT，那麼 NT 是不是可以直接繼承 T 的所有方法呢？

八、defined 類型與 alias 類型是否可以實現方法集合的“繼承”？

8.1 defined 類型與 alias 類型的方法集合

Go 語言中，凡通過類型聲明語法聲明的類型都被稱為 defined 類型，下麵是一些 defined 類型的聲明的例子：

type I interface {
    M1()
    M2()
}
type T int
type NT T // 基於已存在的類型T創建新的defined類型NT
type NI I // 基於已存在的介面類型I創建新defined介面類型NI

新定義的 defined 類型與原 defined 類型是不同的類型，那麼它們的方法集合上又會有什麼關係呢？新類型是否“繼承”原 defined 類型的方法集合呢？

這個問題，我們也要分情況來看。

對於那些基於介面類型創建的 defined 的介面類型，它們的方法集合與原介面類型的方法集合是一致的。但對於基於非介面類型的 defined 類型創建的非介面類型，我們通過下麵例子來看一下：

package main

type T struct{}

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

type T1 T

func main() {
  var t T
  var pt *T
  var t1 T1
  var pt1 *T1

  dumpMethodSet(t)
  dumpMethodSet(t1)

  dumpMethodSet(pt)
  dumpMethodSet(pt1)
}

在這個例子中，我們基於一個 defined 的非介面類型 T 創建了新 defined 類型 T1，並且分別輸出 T1 和 *T1 的方法集合來確認它們是否“繼承”了 T 的方法集合。

運行這個示常式序，我們得到如下結果：

main.T's method set:
- M1

main.T1's method set is empty!

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

*main.T1's method set is empty!

從輸出結果上看，新類型 T1 並沒有“繼承”原 defined 類型 T 的任何一個方法。從邏輯上來說，這也符合 T1 與 T 是兩個不同類型的語義。

基於自定義非介面類型的 defined 類型的方法集合為空的事實，也決定了即便原類型實現了某些介面，基於其創建的 defined 類型也沒有“繼承”這一隱式關聯。也就是說，新 defined 類型要想實現那些介面，仍然需要重新實現介面的所有方法。

那麼，基於類型別名（type alias）定義的新類型有沒有“繼承”原類型的方法集合呢？我們還是來看一個例子：

type T struct{}

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

type T1 = T

func main() {
    var t T
    var pt *T
    var t1 T1
    var pt1 *T1

    dumpMethodSet(t)
    dumpMethodSet(t1)

    dumpMethodSet(pt)
    dumpMethodSet(pt1)
}

這個例子改自之前那個例子，我只是將 T1 的定義方式由類型聲明改成了類型別名，我們看一下這個例子的輸出結果：

main.T's method set:
- M1

main.T's method set:
- M1

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

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

通過這個輸出結果，我們看到，我們的 dumpMethodSet 函數甚至都無法識別出“類型別名”，無論類型別名還是原類型，輸出的都是原類型的方法集合。

由此我們可以得到一個結論：無論原類型是介面類型還是非介面類型，類型別名都與原類型擁有完全相同的方法集合。

九、小結

類型嵌入分為兩種，一種是介面類型的類型嵌入，對於介面類型的類型嵌入我們只要把握好其語義“方法集合併入”就可以了。另外一種是結構體類型的類型嵌入。通過在結構體定義中的嵌入欄位，我們可以實現對嵌入類型的方法集合的“繼承”。

但這種“繼承”並非經典面向對象範式中的那個繼承，Go 中的“繼承”實際是一種組合，更具體點是組合思想下代理（delegate）模式的運用，也就是新類型代理了其嵌入類型的所有方法。當外界調用新類型的方法時，Go 編譯器會首先查找新類型是否實現了這個方法，如果沒有，就會將調用委派給其內部實現了這個方法的嵌入類型的實例去執行，你一定要理解這個原理。

此外，你還要牢記類型嵌入對新類型的方法集合的影響，包括：

  • 結構體類型的方法集合包含嵌入的介面類型的方法集合；

  • 當結構體類型 T 包含嵌入欄位 E 時，*T 的方法集合不僅包含類型 E 的方法集合，還要包含類型 *E 的方法集合。

最後，基於非介面類型的 defined 類型創建的新 defined 類型不會繼承原類型的方法集合，而通過類型別名定義的新類型則和原類型擁有相同的方法集合。

分享是一種快樂，開心是一種態度！
您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Util應用框架基礎(三) - 面向切麵編程(AspectCore AOP)
    本節介紹Util應用框架對AspectCore AOP的使用. 概述 有些問題需要在系統中全局處理,比如記錄異常錯誤日誌. 如果在每個出現問題的地方進行處理,不僅費力,還可能產生大量冗餘代碼,並打斷業務邏輯的編寫. 這類跨多個業務模塊的非功能需求,被稱為橫切關註點. 我們需要把橫切關註點集中管理起來 ...
  • [Rust] 對整形溢出的處理
    1. 兩種不同模式下的整形溢出 坑了個爹的，書上說的沒理解清楚，在Rust程式語言設計中文版3.2中提到了，當使用--release參數進行發佈模式構建時，Rust不會檢測導致panic的整形溢出，這裡需要分兩種情況考慮： 編譯期就可以發現的整形溢出 程式運行過程中會發生的整形溢出 1.1 編譯階段 ...
  • 【PySide6】QChart筆記（一）—— 用QDateTimeAxis作為x軸繪製多條折線圖
    一、QDateTimeAxis簡介 1. 官方描述 https://doc.qt.io/qtforpython-6/PySide6/QtCharts/QDateTimeAxis.html QDateTimeAxis可以用作帶有刻度線、網格線以及陰影的軸。可以通過設置適當的日期時間格式來配置標簽。QD ...
  • 程式員為啥要做副業(05)-業務解決方案締造
    除了技術，副業也可以幫助我們在業務上獲得新認知，保持敏感性。 之前我們在做程式員職業成長服務的時候，發現了一個問題。很多初階的程式員沒法升到中高階，有兩個很大的非技術影響因素： 1 管理能力 每個程式員即使把自己的潛力發揮到極致，成為十倍開發者（ 10x developer），他可以處理的事情也有限 ...
  • 記一次翻頁性能優化
    背景 由於是公司項目，所以不方便給出代碼或者視頻，只能列一些自己畫的流程圖。 大致情況如上，前端有7個顯示區。在對其進行滾動翻頁的時候，存在以下問題： 1. 連續滾輪翻頁，每次所有顯示區刷新完，進行下一次翻頁用時較久。（說人話就是，平均耗時翻頁時間長） 2. 連續滾輪翻頁，會出現一下子翻不動，然後連 ...
  • Java21對虛擬線程進行http壓測使用不同的GC
    Stream流式計算 什麼是Stream流式計算 大數據：存儲+計算 集合、MySql這些的本質都是存儲東西的； 計算都應該交給流來操作！ 一個案例說明：函數式介面、lambda表達式、鏈式編程、Stream流式計算 package org.example.stream; import java.u ...
  • 11、SpringMVC之文件下載和上傳
    創建名為spring_mvc_file的新module，過程參考9.1節和9.5節 11.1、文件下載 11.1.1、創建圖片目錄並放置圖片 11.1.2、頁面請求示例 <a th:href="@{/test/down}">下載圖片</a> 11.1.3、控制器方法示例 package online ...
  • CF1644D Cross Coloring
    Dart 3.0版本新增了很多新特性，包括有名的健全的空安全；同時針對類型（包括Mixin），除之前的abstract修飾符之外，還增加了base，final，interface和sealed等修飾符。今天我們來一起看下，這些類型修飾符，它們有哪些使用場景、使用時有哪些約束，和如何組合使用…… ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類