Go 介面：Go中最強大的魔法,介面應用模式或慣例介紹
一、前置原則
在瞭解介面應用模式之前，我們還先要了解一個前置原則，那就是在實際真正需要的時候才對程式進行抽象。再通俗一些來講，就是不要為了抽象而抽象。介面本質上是一種抽象，它的功能是解耦，所以這條原則也在告訴我們：不要為了使用介面而使用介面。舉一個簡單的例子，如果我們要給一個計算器新增一個整數加法的功能特性，本來一個函式就可以實現：
func Add(a int64, b int64) int64 {
return a+b
}
但如果你非要引入一個介面，結果程式碼可能就變成了這樣：
type Adder interface {
Add(int64, int64) int64
}
func Add(adder Adder, a int64, b int64) int64 {
return adder.Add(a, b)
}
這就會產生一種“過設計”的味道了。
要注意，介面的確可以實現解耦，但它也會引入“抽象”的副作用，或者說介面這種抽象也不是免費的，是有成本的，除了會造成執行效率的下降之外，也會影響程式碼的可讀性。不過這裡你就不要拿我之前講解中的實戰例子去對號入座了，那些例子更多是為了讓你學習 Go 語法的便利而構建的。
在多數情況下，在真實的生產專案中，介面都能給應用設計帶來好處。那麼如果要用介面，我們應該怎麼用呢？怎麼藉助介面來改善程式的設計，讓系統實現我們常說的高內聚和低耦合呢？這就要從 Go 語言的“組合”的設計哲學說起。
二、一切皆組合
2.1 一切皆組合
Go 語言之父 Rob Pike 曾說過：如果 C++ 和 Java 是關於型別層次結構和型別分類的語言，那麼 Go 則是關於組合的語言。如果把 Go 應用程式比作是一臺機器的話，那麼組合關注的就是如何將散落在各個包中的“零件”關聯並組裝到一起。組合是 Go 語言的重要設計哲學之一，而正交性則為組合哲學的落地提供了更為方便的條件。
正交（Orthogonality）是從幾何學中借用的術語，說的是如果兩條線以直角相交，那麼這兩條線就是正交的，比如我們在代數課程中經常用到的座標軸就是這樣。用向量術語說，這兩條直線互不依賴，沿著某一條直線移動，你投影到另一條直線上的位置不變。
在計算機技術中，正交性用於表示某種不相依賴性或是解耦性。如果兩個或更多事物中的一個發生變化，不會影響其他事物，那麼這些事物就是正交的。比如，在設計良好的系統中，資料庫程式碼與使用者介面是正交的：你可以改動介面，而不影響資料庫；更換資料庫，而不用改動介面。
程式語言的語法元素間和語言特性也存在著正交的情況，並且透過將這些正交的特性組合起來，我們可以實現更為高階的特性。在語言設計層面，Go 語言就為廣大 Gopher 提供了諸多正交的語法元素供後續組合使用，包括：
- Go 語言無型別體系（
Type Hierarchy），沒有父子類的概念，型別定義是正交獨立的； - 方法和型別是正交的，每種型別都可以擁有自己的方法集合，方法本質上只是一個將
receiver引數作為第一個引數的函式而已； - 介面與它的實現者之間無“顯式關聯”，也就說介面與 Go 語言其他部分也是正交的。
在這些正交語法元素當中，介面作為 Go 語言提供的具有天然正交性的語法元素，在 Go 程式的靜態結構搭建與耦合設計中扮演著至關重要的角色。 而要想知道介面究竟扮演什麼角色，我們就先要了解組合的方式。
構建 Go 應用程式的靜態骨架結構有兩種主要的組合方式，如下圖所示：
我們看到，這兩種組合方式分別為垂直組合和水平組合，那這兩種組合的各自含義與應用範圍是什麼呢？下面我們分別看看這兩種組合。
2.2 垂直組合
垂直組合更多用在將多個型別(如上圖中的 T1、I1 等)透過“型別嵌入(Type Embedding)”的方式實現新型別(如 NT1)的定義。
傳統物件導向程式語言(比如:C++)大多是透過繼承的方式建構出自己的型別體系的,但 Go 語言並沒有型別體系的概念。Go 語言透過型別的組合而不是繼承讓單一型別承載更多的功能。由於這種方式與硬體配置升級的垂直擴充套件很類似,所以這裡我們叫它垂直組合。
又因為不是繼承,那麼透過垂直組合定義的新型別與被嵌入的型別之間就沒有所謂“父子關係”的概念了,也沒有向上、向下轉型(Type Casting),被嵌入的型別也不知道將其嵌入的外部型別的存在。呼叫方法時,方法的匹配取決於方法名字,而不是型別。
這樣的垂直組合更多應用在新型別的定義方面。透過這種垂直組合，我們可以達到方法實現的複用、介面定義重用等目的。
在實現層面,Go 語言透過型別嵌入(Type Embedding)實現垂直組合,組合方式主要有以下幾種。
2.2.1 第一種：透過嵌入介面構建介面
透過在介面定義中嵌入其他介面型別，實現介面行為聚合，組成大介面。這種方式在標準庫中非常常見，也是 Go 介面型別定義的慣例。
比如這個 ReadWriter 介面型別就採用了這種型別嵌入方式：
// $GOROOT/src/io/io.go
type ReadWriter interface {
Reader
Writer
}
2.2.2 第二種：透過嵌入介面構建結構體型別
這裡我們直接來看一個透過嵌入介面型別建立新結構體型別的例子：
type MyReader struct {
io.Reader // underlying reader
N int64 // max bytes remaining
}
在結構體中嵌入介面，可以用於快速構建滿足某一個介面的結構體型別，來滿足某單元測試的需要，之後我們只需要實現少數需要的介面方法就可以了。尤其是將這樣的結構體型別變數傳遞賦值給大介面的時候，就更能體現嵌入介面型別的優勢了。
2.2.3 第三種：透過嵌入結構體型別構建新結構體型別
在結構體中嵌入介面型別名和在結構體中嵌入其他結構體,都是“委派模式(delegate)”的一種應用。對新結構體型別的方法呼叫,可能會被“委派”給該結構體內部嵌入的結構體的例項,透過這種方式構建的新結構體型別就“繼承”了被嵌入的結構體的方法的實現。
現在我們可以知道，包括嵌入介面型別在內的各種垂直組合更多用於型別定義層面，本質上它是一種型別組合，也是一種型別之間的耦合方式。
接著，我們來看看水平組合。
2.3 水平組合
當我們透過垂直組合將一個個型別建立完畢後，就好比我們已經建立了整個應用程式骨架中的“器官”，那這些器官手、手臂等，那麼這些“器官”之間又是透過關節連線在一起的。
在 Go 應用靜態骨架中，什麼元素經常扮演著“關節”的角色呢？我們先來看個例子，假設現在我們有一個任務，要編寫一個函式，實現將一段資料寫入磁碟的功能。通常我們都可以很容易地寫出下面的函式：
func Save(f *os.File, data []byte) error
我們看到,這個函式使用一個 *os.File 來表示資料寫入的目的地,這個函式實現後可以工作得很好。但這裡依舊存在一些問題,我們來看一下。
首先,這個函式很難測試。os.File 是一個封裝了磁碟檔案描述符(又稱控制程式碼)的結構體,只有透過開啟或建立真實磁碟檔案才能獲得這個結構體的例項,這就意味著,如果我們要對 Save 這個函式進行單元測試,就必須使用真實的磁碟檔案。測試過程中,透過 Save 函式寫入檔案後,我們還需要再次操作檔案、讀取剛剛寫入的內容來判斷寫入內容是否正確,並且每次測試結束前都要對建立的臨時檔案進行清理,避免給後續的測試帶去影響。
其次,Save 函式違背了介面分離原則。根據業界廣泛推崇的 Robert Martin(Bob 大叔)的介面分離原則(ISP 原則,Interface Segregation Principle),也就是客戶端不應該被迫依賴他們不使用的方法,我們會發現 os.File 不僅包含 Save 函式需要的與寫資料相關的 Write 方法,還包含了其他與儲存資料到檔案操作不相關的方法。比如,你也可以看下 *os.File 包含的這些方法:
func (f *File) Chdir() error
func (f *File) Chmod(mode FileMode) error
func (f *File) Chown(uid, gid int) error
... ...
這種讓 Save 函式被迫依賴它所不使用的方法的設計違反了 ISP 原則。
最後,Save 函式對 os.File 的強依賴讓它失去了擴充套件性。像 Save 這樣的功能函式,它日後很大可能會增加向網路儲存寫入資料的功能需求。但如果到那時我們再來改變 Save 函式的函式簽名(引數列表 + 返回值)的話,將影響到 Save 函式的所有呼叫者。
綜合考慮這幾種原因,我們發現 Save 函式所在的“器官”與 os.File 所在的“器官”之間採用了一種硬連線的方式,而以 os.File 這樣的結構體作為“關節”讓它連線的兩個“器官”喪失了相互運動的自由度,讓它與它連線的兩個“器官”構成的聯結體變得“僵直”。
那麼,我們應該如何更換“關節”來改善 Save 的設計呢?我們來試試介面。新版的 Save 函式原型如下:
func Save(w io.Writer, data []byte) error
可以看到,我們用 io.Writer 介面型別替換掉了 *os.File。這樣一來,新版 Save 的設計就符合了介面分離原則,因為 io.Writer 僅包含一個 Write 方法,而且這個方法恰恰是 Save 唯一需要的方法。
另外,這裡我們以 io.Writer 介面型別表示資料寫入的目的地,既可以支援向磁碟寫入,也可以支援向網路儲存寫入,並支援任何實現了 Write 方法的寫入行為,這讓 Save 函式的擴充套件性得到了質的提升。
還有一點,也是之前我們一直強調的,介面本質是契約,具有天然的降低耦合的作用。基於這點,我們對 Save 函式的測試也將變得十分容易,比如下面示例程式碼:
func TestSave(t *testing.T) {
b := make([]byte, 0, 128)
buf := bytes.NewBuffer(b)
data := []byte("hello, golang")
err := Save(buf, data)
if err != nil {
t.Errorf("want nil, actual %s", err.Error())
}
saved := buf.Bytes()
if !reflect.DeepEqual(saved, data) {
t.Errorf("want %s, actual %s", string(data), string(saved))
}
}
在這段程式碼中,我們透過 bytes.NewBuffer 建立了一個 *bytes.Buffer 型別變數 buf,由於 bytes.Buffer 實現了 Write 方法,進而實現了 io.Writer 介面,我們可以合法地將變數 buf 傳遞給 Save 函式。之後我們可以從 buf 中取出 Save 函式寫入的資料內容與預期的資料做比對,就可以達到對 Save 函式進行單元測試的目的了。在整個測試過程中,我們不需要建立任何磁碟檔案或建立任何網路連線。
看到這裡,你應該感受到了,用介面作為“關節(連線點)”的好處很多!像上面圖中展示的那樣,介面可以將各個型別水平組合(連線)在一起。透過介面的編織,整個應用程式不再是一個個孤立的“器官”,而是一幅完整的、有靈活性和擴充套件性的靜態骨架結構。
現在，我們已經確定了介面承擔了應用骨架的“關節”角色，接下來我們來看看介面是如何演好這一角色的。
三、介面應用的幾種模式
前面已經說了，以介面為“關節”的水平組合方式，可以將各個垂直組合出的型別“耦合”在一起，從而編織出程式靜態骨架。而透過介面進行水平組合的基本模式就是：使用接受介面型別引數的函式或方法。在這個基本模式基礎上，還有其他幾種“衍生品”。我們先從基本模式說起，再往外延伸。
3.1 基本模式
接受介面型別引數的函式或方法是水平組合的基本語法，形式是這樣的：
func YourFuncName(param YourInterfaceType)
我們套用骨架關節的概念，用這幅圖來表示上面基本模式語法的運用方法：
我們看到,函式 / 方法引數中的介面型別作為“關節(連線點)”,支援將位於多個包中的多個型別與 YourFuncName 函式連線到一起,共同實現某一新特性。
同時,介面型別和它的實現者之間隱式的關係卻在不經意間滿足了:依賴抽象(DIP)、里氏替換原則(LSP)、介面隔離(ISP)等程式碼設計原則,這在其他語言中是需要很“刻意”地設計謀劃的,但對 Go 介面來看,這一切卻是自然而然的。
這一水平組合的基本模式在 Go 標準庫、Go 社群第三方包中有著廣泛應用，其他幾種模式也是從這個模式衍生的。下面我們看一下其他的各個衍生模式。
3.2 建立模式
Go 社群流傳一個經驗法則：“接受介面，返回結構體（Accept interfaces, return structs）”，這其實就是一種把介面作為“關節”的應用模式。我這裡把它叫做建立模式，是因為這個經驗法則多用於建立某一結構體型別的例項。
下面是 Go 標準庫中，運用建立模式建立結構體例項的程式碼摘錄：
// $GOROOT/src/sync/cond.go
type Cond struct {
... ...
L Locker
}
func NewCond(l Locker) *Cond {
return &Cond{L: l}
}
// $GOROOT/src/log/log.go
type Logger struct {
mu sync.Mutex
prefix string
flag int
out io.Writer
buf []byte
}
func New(out io.Writer, prefix string, flag int) *Logger {
return &Logger{out: out, prefix: prefix, flag: flag}
}
// $GOROOT/src/log/log.go
type Writer struct {
err error
buf []byte
n int
wr io.Writer
}
func NewWriterSize(w io.Writer, size int) *Writer {
// Is it already a Writer?
b, ok := w.(*Writer)
if ok && len(b.buf) >= size {
return b
}
if size <= 0 {
size = defaultBufSize
}
return &Writer{
buf: make([]byte, size),
wr: w,
}
}
我們看到，建立模式在 sync、log、bufio 包中都有應用。以上面 log 包的 New 函式為例，這個函式用於例項化一個 log.Logger 例項，它接受一個 io.Writer 介面型別的引數，返回 *log.Logger。從 New 的實現上來看，傳入的 out 引數被作為初值賦值給了 log.Logger 結構體欄位 out。
建立模式透過介面，在 NewXXX 函式所在包與介面的實現者所在包之間建立了一個連線。大多數包含介面型別欄位的結構體的例項化，都可以使用建立模式實現。這個模式比較容易理解，我們就不再深入了。
3.3 包裝器模式
在基本模式的基礎上，當返回值的型別與引數型別相同時，我們能得到下面形式的函式原型：
func YourWrapperFunc(param YourInterfaceType) YourInterfaceType
透過這個函式，我們可以實現對輸入引數的型別的包裝，並在不改變被包裝型別（輸入引數型別）的定義的情況下，返回具備新功能特性的、實現相同介面型別的新型別。這種介面應用模式我們叫它包裝器模式，也叫裝飾器模式。包裝器多用於對輸入資料的過濾、變換等操作。
下面就是 Go 標準庫中一個典型的包裝器模式的應用：
// $GOROOT/src/io/io.go
func LimitReader(r Reader, n int64) Reader { return &LimitedReader{r, n} }
type LimitedReader struct {
R Reader // underlying reader
N int64 // max bytes remaining
}
func (l *LimitedReader) Read(p []byte) (n int, err error) {
// ... ...
}
透過上面的程式碼，我們可以看到，透過 LimitReader 函式的包裝後，我們得到了一個具有新功能特性的 io.Reader 介面的實現型別，也就是 LimitedReader。這個新型別在 Reader 的語義基礎上實現了對讀取位元組個數的限制。
接下來我們再具體看 LimitReader 的一個使用示例：
func main() {
r := strings.NewReader("hello, gopher!\n")
lr := io.LimitReader(r, 4)
if _, err := io.Copy(os.Stdout, lr); err != nil {
log.Fatal(err)
}
}
執行這個示例，我們得到了這個結果：
hell
我們看到，當採用經過 LimitReader 包裝後返回的 io.Reader 去讀取內容時，讀到的是經過 LimitedReader 約束後的內容，也就是隻讀到了原字串前面的 4 個位元組：“hell”。
由於包裝器模式下的包裝函式（如上面的 LimitReader）的返回值型別與引數型別相同，因此我們可以將多個接受同一介面型別引數的包裝函式組合成一條鏈來呼叫，形式是這樣的：
YourWrapperFunc1(YourWrapperFunc2(YourWrapperFunc3(...)))
我們在上面示例的基礎上自定義一個包裝函式：CapReader，透過這個函式的包裝，我們能得到一個可以將輸入的資料轉換為大寫的 Reader 介面實現：
func CapReader(r io.Reader) io.Reader {
return &capitalizedReader{r: r}
}
type capitalizedReader struct {
r io.Reader
}
func (r *capitalizedReader) Read(p []byte) (int, error) {
n, err := r.r.Read(p)
if err != nil {
return 0, err
}
q := bytes.ToUpper(p)
for i, v := range q {
p[i] = v
}
return n, err
}
func main() {
r := strings.NewReader("hello, gopher!\n")
r1 := CapReader(io.LimitReader(r, 4))
if _, err := io.Copy(os.Stdout, r1); err != nil {
log.Fatal(err)
}
}
這裡，我們將 CapReader 和 io.LimitReader 串在了一起形成一條呼叫鏈，這條呼叫鏈的功能變為：擷取輸入資料的前四個位元組並將其轉換為大寫字母。這個示例的執行結果與我們預期功能也是一致的：
HELL
3.4 介面卡模式
介面卡模式不是基本模式的直接衍生模式，但這種模式是後面中介軟體模式的前提，所以我們需要簡單介紹下這個模式。
介面卡模式的核心是介面卡函式型別（Adapter Function Type）。介面卡函式型別是一個輔助水平組合實現的“工具”型別。這裡我要再強調一下，它是一個型別。它可以將一個滿足特定函式簽名的普通函式，顯式轉換成自身型別的例項，轉換後的例項同時也是某個介面型別的實現者。
這裡，我們來看一個應用 http.HandlerFunc 的例子：
func greetings(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Welcome!")
}
func main() {
http.ListenAndServe(":8080", http.HandlerFunc(greetings))
}
我們可以看到，這個例子透過 http.HandlerFunc 這個介面卡函式型別，將普通函式 greetings 快速轉化為滿足 http.Handler 介面的型別。而 http.HandleFunc 這個介面卡函式型別的定義是這樣的：
// $GOROOT/src/net/http/server.go
type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}
type HandlerFunc func(ResponseWriter, *Request)
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
f(w, r)
}
經過 HandlerFunc 的適配轉化後，我們就可以將它的例項用作實參，傳遞給接收 http.Handler 介面的 http.ListenAndServe 函式，從而實現基於介面的組合。
3.5 中介軟體（Middleware）
最後，我們看下中介軟體這個應用模式。中介軟體（Middleware）這個詞的含義可大可小。在 Go Web 程式設計中，“中介軟體”常常指的是一個實現了 http.Handler 介面的 http.HandlerFunc 型別例項。實質上，這裡的中介軟體就是包裝模式和介面卡模式結合的產物。
我們來看一個例子：
func validateAuth(s string) error {
if s != "123456" {
return fmt.Errorf("%s", "bad auth token")
}
return nil
}
func greetings(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Welcome!")
}
func logHandler(h http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
t := time.Now()
log.Printf("[%s] %q %v\n", r.Method, r.URL.String(), t)
h.ServeHTTP(w, r)
})
}
func authHandler(h http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
err := validateAuth(r.Header.Get("auth"))
if err != nil {
http.Error(w, "bad auth param", http.StatusUnauthorized)
return
}
h.ServeHTTP(w, r)
})
}
func main() {
http.ListenAndServe(":8080", logHandler(authHandler(http.HandlerFunc(greetings))))
}
我們看到，所謂中介軟體（如：logHandler、authHandler）本質就是一個包裝函式（支援鏈式呼叫），但它的內部利用了介面卡函式型別（http.HandlerFunc），將一個普通函式（比如例子中的幾個匿名函式）轉型為實現了 http.Handler 的型別的例項。
執行這個示例，並用 curl 工具命令對其進行測試，我們可以得到下面結果：
$curl http://localhost:8080
bad auth param
$curl -H "auth:123456" localhost:8080/
Welcome!
從測試結果上看，中介軟體 authHandler 起到了對 HTTP 請求進行鑑權的作用。
四、介面使用的注意事項
儘量避免使用空介面作為函式引數型別
Go 語言之父 Rob Pike 曾說過：空介面不提供任何資訊（The empty interface says nothing）。我們應該怎麼理解這句話的深層含義呢？
在 Go 語言中，一方面你不用像 Java 那樣顯式宣告某個型別實現了某個介面，但另一方面，你又必須宣告這個介面，這又與介面在 Java 等靜態型別語言中的工作方式更加一致。
這種不需要型別顯式宣告實現了某個介面的方式，可以讓種類繁多的型別與介面匹配，包括那些存量的、並非由你編寫的程式碼以及你無法編輯的程式碼（比如：標準庫）。Go 的這種處理方式兼顧安全性和靈活性，其中，這個安全性就是由 Go 編譯器來保證的，而為編譯器提供輸入資訊的恰恰是介面型別的定義。
比如我們看下面的介面：
// $GOROOT/src/io/io.go
type Reader interface {
Read(p []byte) (n int, err error)
}
Go 編譯器透過解析這個介面定義，得到介面的名字資訊以及它的方法資訊，在為這個介面型別引數賦值時，編譯器就會根據這些資訊對實參進行檢查。這時你可以想一下，如果函式或方法的引數型別為空介面 interface{}，會發生什麼呢？
這恰好就應了 Rob Pike 的那句話：“空介面不提供任何資訊”。這裡“提供”一詞的物件不是開發者，而是編譯器。在函式或方法引數中使用空介面型別，就意味著你沒有為編譯器提供關於傳入實引數據的任何資訊，所以，你就會失去靜態型別語言型別安全檢查的“保護屏障”，你需要自己檢查類似的錯誤，並且直到執行時才能發現此類錯誤。
所以，建議 Gopher 儘可能地抽象出帶有一定行為契約的介面，並將它作為函式引數型別，儘量不要使用可以“逃過”編譯器型別安全檢查的空介面型別（interface{}）。
在這方面，Go 標準庫已經為我們作出了“表率”。全面搜尋標準庫後，你可以發現以 interface{} 為引數型別的方法和函式少之甚少。不過，也還有，使用 interface{} 作為引數型別的函式或方法主要有兩類：
- 容器演算法類，比如：
container下的heap、list和ring包、sort包、sync.Map等； - 格式化 / 日誌類，比如：
fmt包、log包等。
這些使用 interface{} 作為引數型別的函式或方法都有一個共同特點，就是它們面對的都是未知型別的資料，所以在這裡使用具有“泛型”能力的 interface{} 型別。
五、小結
在使用介面前一定要搞清楚自己使用介面的原因，千萬不能為了使用介面而使用介面。
介面與 Go 的“組合”的設計哲學息息相關。在 Go 語言中，組合是 Go 程式間各個部分的主要耦合方式。垂直組合可實現方法實現和介面定義的重用，更多用於在新型別的定義方面。而水平組合更多將介面作為“關節”，將各個垂直組合出的型別“耦合”在一起，從而編制出程式的靜態骨架。
透過介面進行水平組合的基本模式，是“使用接受介面型別引數的函式或方法”，在這一基本模式的基礎上，我們還了解了幾個衍生模式：建立模式、包裝器模式與中介軟體模式。此外，我們還學習了一個輔助水平組合實現的“工具”型別：介面卡函式型別，它也是實現中介軟體模式的前提。
最後需要我們牢記的是：我們要儘量避免使用空介面作為函式引數型別。一旦使用空介面作為函式引數型別，你將失去編譯器為你提供的型別安全保護屏障。