在 Go 語言中,我為什麼使用介面
強調一下是我個人的見解以及介面在 Go 語言中的意義。
如果您寫程式碼已經有了一段時間,我可能不需要過多解釋介面所帶來的好處,但是在深入探討 Go 語言中的介面前,我想花一兩分鐘先來簡單介紹一下介面。 如果您對介面很熟悉,請先跳過下面這段。
介面的簡單介紹
在任一程式語言中,介面——方法或行為的集合,在功能和該功能的使用者之間構建了一層薄薄的抽象層。在使用介面時,並不需要了解底層函式是如何實現的,因為介面隔離了各個部分(劃重點)。
跟不使用介面相比,使用介面的最大好處就是可以使程式碼變得簡潔。例如,您可以建立多個元件,通過介面讓它們以統一的方式互動,儘管這些元件的底層實現差異很大。這樣就可以在編譯甚至執行的時候動態替換這些元件。
用 Go 的 io.Reader
介面舉個例子。io.Reader
介面的所有實現都有 Read(p []byte) (n int, err error)
函式。使用 io.Reader
介面的使用者不需要知道使用這個 Read
函式的時候那些位元組從何而來。
具體到 Go 語言
在我使用 Go 語言的過程中,與我使用過的其他任何程式語言相比,我經常發現其他的、不那麼明顯的使用介面的原因。今天,我將介紹一個很普遍的,也是我遇到了很多次的使用介面的原因。
Go 語言沒有建構函式
很多程式語言都有建構函式。建構函式是定義自定義型別(即 OO 語言中的類)時使用的一種建立物件的方法,它可以確保必須執行的任何初始化邏輯均已執行。
例如,假設所有 widgets
都必須有一個不變的,系統分配的識別符號。在 Java 中,這很容易實現:
package io.krancour.widget; import java.util.UUID; public class Widget { private String id; // 使用建構函式初始化 public Widget() { id = UUID.randomUUID().toString(); } public String getId() { return id; } } class App { public static void main( String[] args ){ Widget w = new Widget(); System.out.println(w.getId()); } }
從上面這個例子可以看到,沒有執行初始化邏輯就無法例項化一個新的 Widget
。
但是 Go 語言沒有此功能。
在 Go 語言中,可以直接例項化一個自定義型別。
定義一個 Widget
型別:
package widgets
type Widget struct {
id string
}
func (w Widget) ID() string {
return w.id
}
可以像這樣例項化和使用一個 widget
:
package main
import (
"fmt"
"github.com/krancour/widgets"
)
func main() {
w := widgets.Widget{}
fmt.Println(w.ID())
}
如果執行此示例,那麼(也許)意料之中的結果是,打印出的 ID 是空字串,因為它從未被初始化,而空字串是字串的“零值”。 我們可以在 widgets
包中新增一個類似於建構函式的函式來處理初始化:
package widgets
import uuid "github.com/satori/go.uuid"
type Widget struct {
id string
}
func NewWidget() Widget {
return Widget{
id: uuid.NewV4().String(),
}
}
func (w Widget) ID() string {
return w.id
}
然後我們簡單地修改 main
來使用這個類似於建構函式的新函式:
package main
import (
"fmt"
"github.com/krancour/widgets"
)
func main() {
w := widgets.NewWidget()
fmt.Println(w.ID())
}
執行該程式,我們得到了想要的結果。
但是仍然存在一個嚴重問題!我們的 widgets
包沒有強制使用者在初始一個 widget
的時候使用我們的建構函式。
變數私有化
首先我們嘗試把自定義型別的變數私有化,以此來強制使用者使用我們規定的建構函式來初始化 widget
。在 Go 語言中,型別名、函式名的首字母是否大寫決定它們是否可被其他包訪問。名稱首字母大寫的可被訪問(也就是 public
),而名稱首字母小寫的不可被訪問(也就是 private
)。所以我們把型別 Widget
改為型別 widget
:
package widgets
import uuid "github.com/satori/go.uuid"
type widget struct {
id string
}
func NewWidget() widget {
return widget{
id: uuid.NewV4().String(),
}
}
func (w widget) ID() string {
return w.id
}
我們的 main
程式碼保持不變,這次我們得到了一個 ID 。這比我們想要的要近了一步,但是我們在此過程中犯了一個不太明顯的錯誤。類似於建構函式的 NewWidget
函式返回了一個私有的例項。儘管編譯器對此不會報錯,但這是一種不好的做法,下面是原因解釋。
在 Go 語言中,包*是複用的基本單位。其他語言中的類*是複用的基本單位。如前所述,任何無法被外部訪問的內容實質上都是“包私有”,是該包的內部實現細節,對於使用這個包的使用者來說不重要。因此,Go 的文件生成工具 godoc
不會為私有的函式、型別等生成文件。
當一個公開的建構函式返回一個私有的 widget
例項,實際上就陷入了一條死衚衕。呼叫這個函式的人哪怕有這個例項,也絕對在文件裡找不到任何關於這個例項型別的描述,也更不知道 ID()
這個函式。Go 社群非常重視文件,所以這樣做是不會被接受的。
輪到介面上場了
回顧一下,到目前為止,我們寫了一個類似於建構函式的函式來解決 Go 語言缺乏建構函式的問題,但是為了確保人們用該函式而不是直接例項化 Widget
,我們更改了該型別的可見性——將其重新命名為 widget
,即私有化了。雖然編譯器不會報錯,但是文件中不會出現對這個私有型別的描述。不過,我們距離想要的目標還近了一步。接下來就要使用介面來完成後續的了。
通過建立一個*可被訪問的*、widget
型別可以實現的介面,我們的建構函式可以返回一個公開的型別例項,並且會顯示在 godoc
文件中。同時,這個介面的底層實現依然是私有的,使用者無法直接建立一個例項。
package widgets
import uuid "github.com/satori/go.uuid"
// Widget is a ...
type Widget interface {
// ID 返回這個 widget 的唯一識別符號
ID() string
}
type widget struct {
id string
}
// NewWidget() 返回一個新的 Widget 例項
func NewWidget() Widget {
return widget{
id: uuid.NewV4().String(),
}
}
func (w widget) ID() string {
return w.id
}
總結
我希望我已經充分地闡述了 Go 語言的這一特質——建構函式的缺失反而促進了介面的使用。
在我的下一篇文章中,我將介紹一種幾乎與之相反的場景——在其他語言中要使用介面但是在 Go 語言中卻不必。
via: https://medium.com/@kent.rancourt/go-pointers-why-i-use-interfaces-in-go-338ae0bdc9e4
作者:Kent Rancourt 譯者:zhiyu-tracy-yang 校對:polaris1119