強調一下是我個人的見解以及接口在 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