一、前置原則

在了解接口應用模式之前，我們還先要了解一個前置原則，那就是在實際真正需要的時候才對程序進行抽象。再通俗一些來講，就是不要為了抽象而抽象。接口本質(zhì)上是一種抽象，它的功能是解耦，所以這條原則也在告訴我們：不要為了使用接口而使用接口。舉一個簡單的例子，如果我們要給一個計算器添加一個整數(shù)加法的功能特性，本來一個函數(shù)就可以實現(xiàn)：

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)
}

這就會產(chǎn)生一種“過設計”的味道了。

要注意，接口的確可以實現(xiàn)解耦，但它也會引入“抽象”的副作用，或者說接口這種抽象也不是免費的，是有成本的，除了會造成運行效率的下降之外，也會影響代碼的可讀性。不過這里你就不要拿我之前講解中的實戰(zhàn)例子去對號入座了，那些例子更多是為了讓你學習 Go 語法的便利而構建的。

在多數(shù)情況下，在真實的生產(chǎn)項目中，接口都能給應用設計帶來好處。那么如果要用接口，我們應該怎么用呢？怎么借助接口來改善程序的設計，讓系統(tǒng)實現(xiàn)我們常說的高內(nèi)聚和低耦合呢？這就要從 Go 語言的“組合”的設計哲學說起。

二、一切皆組合

2.1 一切皆組合

Go 語言之父 Rob Pike 曾說過：如果 C++ 和 Java 是關于類型層次結構和類型分類的語言，那么 Go 則是關于組合的語言。如果把 Go 應用程序比作是一臺機器的話，那么組合關注的就是如何將散落在各個包中的“零件”關聯(lián)并組裝到一起。組合是 Go 語言的重要設計哲學之一，而正交性則為組合哲學的落地提供了更為方便的條件。

正交（Orthogonality）是從幾何學中借用的術語，說的是如果兩條線以直角相交，那么這兩條線就是正交的，比如我們在代數(shù)課程中經(jīng)常用到的坐標軸就是這樣。用向量術語說，這兩條直線互不依賴，沿著某一條直線移動，你投影到另一條直線上的位置不變。

在計算機技術中，正交性用于表示某種不相依賴性或是解耦性。如果兩個或更多事物中的一個發(fā)生變化，不會影響其他事物，那么這些事物就是正交的。比如，在設計良好的系統(tǒng)中，數(shù)據(jù)庫代碼與用戶界面是正交的：你可以改動界面，而不影響數(shù)據(jù)庫；更換數(shù)據(jù)庫，而不用改動界面。

編程語言的語法元素間和語言特性也存在著正交的情況，并且通過將這些正交的特性組合起來，我們可以實現(xiàn)更為高級的特性。在語言設計層面，Go 語言就為廣大 Gopher 提供了諸多正交的語法元素供后續(xù)組合使用，包括：

• Go 語言無類型體系（Type Hierarchy），沒有父子類的概念，類型定義是正交獨立的；
• 方法和類型是正交的，每種類型都可以擁有自己的方法集合，方法本質(zhì)上只是一個將 receiver 參數(shù)作為第一個參數(shù)的函數(shù)而已；
• 接口與它的實現(xiàn)者之間無“顯式關聯(lián)”，也就說接口與 Go 語言其他部分也是正交的。

在這些正交語法元素當中，接口作為 Go 語言提供的具有天然正交性的語法元素，在 Go 程序的靜態(tài)結構搭建與耦合設計中扮演著至關重要的角色。 而要想知道接口究竟扮演什么角色，我們就先要了解組合的方式。

構建 Go 應用程序的靜態(tài)骨架結構有兩種主要的組合方式，如下圖所示：

我們看到，這兩種組合方式分別為垂直組合和水平組合，那這兩種組合的各自含義與應用范圍是什么呢？下面我們分別看看這兩種組合。

2.2 垂直組合

垂直組合更多用在將多個類型(如上圖中的 T1、I1 等)通過“類型嵌入(Type Embedding)”的方式實現(xiàn)新類型(如 NT1)的定義。

傳統(tǒng)面向?qū)ο缶幊陶Z言(比如:C++)大多是通過繼承的方式建構出自己的類型體系的,但 Go 語言并沒有類型體系的概念。Go 語言通過類型的組合而不是繼承讓單一類型承載更多的功能。由于這種方式與硬件配置升級的垂直擴展很類似,所以這里我們叫它垂直組合。

又因為不是繼承,那么通過垂直組合定義的新類型與被嵌入的類型之間就沒有所謂“父子關系”的概念了,也沒有向上、向下轉(zhuǎn)型(Type Casting),被嵌入的類型也不知道將其嵌入的外部類型的存在。調(diào)用方法時,方法的匹配取決于方法名字,而不是類型。

這樣的垂直組合更多應用在新類型的定義方面。通過這種垂直組合，我們可以達到方法實現(xiàn)的復用、接口定義重用等目的。

在實現(xiàn)層面,Go 語言通過類型嵌入(Type Embedding)實現(xiàn)垂直組合,組合方式主要有以下幾種。

2.2.1 第一種：通過嵌入接口構建接口

通過在接口定義中嵌入其他接口類型，實現(xiàn)接口行為聚合，組成大接口。這種方式在標準庫中非常常見，也是 Go 接口類型定義的慣例。

比如這個 ReadWriter 接口類型就采用了這種類型嵌入方式：

// $GOROOT/src/io/io.go
type ReadWriter interface {
    Reader
    Writer
}

2.2.2 第二種：通過嵌入接口構建結構體類型

這里我們直接來看一個通過嵌入接口類型創(chuàng)建新結構體類型的例子：

type MyReader struct {
  io.Reader // underlying reader
  N int64   // max bytes remaining
}

在結構體中嵌入接口，可以用于快速構建滿足某一個接口的結構體類型，來滿足某單元測試的需要，之后我們只需要實現(xiàn)少數(shù)需要的接口方法就可以了。尤其是將這樣的結構體類型變量傳遞賦值給大接口的時候，就更能體現(xiàn)嵌入接口類型的優(yōu)勢了。

2.2.3 第三種：通過嵌入結構體類型構建新結構體類型

在結構體中嵌入接口類型名和在結構體中嵌入其他結構體,都是“委派模式(delegate)”的一種應用。對新結構體類型的方法調(diào)用,可能會被“委派”給該結構體內(nèi)部嵌入的結構體的實例,通過這種方式構建的新結構體類型就“繼承”了被嵌入的結構體的方法的實現(xiàn)。

現(xiàn)在我們可以知道，包括嵌入接口類型在內(nèi)的各種垂直組合更多用于類型定義層面，本質(zhì)上它是一種類型組合，也是一種類型之間的耦合方式。

接著，我們來看看水平組合。

2.3 水平組合

當我們通過垂直組合將一個個類型建立完畢后，就好比我們已經(jīng)建立了整個應用程序骨架中的“器官”，那這些器官手、手臂等，那么這些“器官”之間又是通過關節(jié)連接在一起的。

在 Go 應用靜態(tài)骨架中，什么元素經(jīng)常扮演著“關節(jié)”的角色呢？我們先來看個例子，假設現(xiàn)在我們有一個任務，要編寫一個函數(shù)，實現(xiàn)將一段數(shù)據(jù)寫入磁盤的功能。通常我們都可以很容易地寫出下面的函數(shù)：

func Save(f *os.File, data []byte) error

我們看到,這個函數(shù)使用一個 *os.File 來表示數(shù)據(jù)寫入的目的地,這個函數(shù)實現(xiàn)后可以工作得很好。但這里依舊存在一些問題,我們來看一下。

首先,這個函數(shù)很難測試。os.File 是一個封裝了磁盤文件描述符(又稱句柄)的結構體,只有通過打開或創(chuàng)建真實磁盤文件才能獲得這個結構體的實例,這就意味著,如果我們要對 Save 這個函數(shù)進行單元測試,就必須使用真實的磁盤文件。測試過程中,通過 Save 函數(shù)寫入文件后,我們還需要再次操作文件、讀取剛剛寫入的內(nèi)容來判斷寫入內(nèi)容是否正確,并且每次測試結束前都要對創(chuàng)建的臨時文件進行清理,避免給后續(xù)的測試帶去影響。

其次,Save 函數(shù)違背了接口分離原則。根據(jù)業(yè)界廣泛推崇的 Robert Martin(Bob 大叔)的接口分離原則(ISP 原則,Interface Segregation Principle),也就是客戶端不應該被迫依賴他們不使用的方法,我們會發(fā)現(xiàn) os.File 不僅包含 Save 函數(shù)需要的與寫數(shù)據(jù)相關的 Write 方法,還包含了其他與保存數(shù)據(jù)到文件操作不相關的方法。比如,你也可以看下 *os.File 包含的這些方法:

func (f *File) Chdir() error
func (f *File) Chmod(mode FileMode) error
func (f *File) Chown(uid, gid int) error
... ...

這種讓 Save 函數(shù)被迫依賴它所不使用的方法的設計違反了 ISP 原則。

最后,Save 函數(shù)對 os.File 的強依賴讓它失去了擴展性。像 Save 這樣的功能函數(shù),它日后很大可能會增加向網(wǎng)絡存儲寫入數(shù)據(jù)的功能需求。但如果到那時我們再來改變 Save 函數(shù)的函數(shù)簽名(參數(shù)列表 + 返回值)的話,將影響到 Save 函數(shù)的所有調(diào)用者。

綜合考慮這幾種原因,我們發(fā)現(xiàn) Save 函數(shù)所在的“器官”與 os.File 所在的“器官”之間采用了一種硬連接的方式,而以 os.File 這樣的結構體作為“關節(jié)”讓它連接的兩個“器官”喪失了相互運動的自由度,讓它與它連接的兩個“器官”構成的聯(lián)結體變得“僵直”。

那么,我們應該如何更換“關節(jié)”來改善 Save 的設計呢?我們來試試接口。新版的 Save 函數(shù)原型如下:

func Save(w io.Writer, data []byte) error

可以看到,我們用 io.Writer 接口類型替換掉了 *os.File。這樣一來,新版 Save 的設計就符合了接口分離原則,因為 io.Writer 僅包含一個 Write 方法,而且這個方法恰恰是 Save 唯一需要的方法。

另外,這里我們以 io.Writer 接口類型表示數(shù)據(jù)寫入的目的地,既可以支持向磁盤寫入,也可以支持向網(wǎng)絡存儲寫入,并支持任何實現(xiàn)了 Write 方法的寫入行為,這讓 Save 函數(shù)的擴展性得到了質(zhì)的提升。

還有一點,也是之前我們一直強調(diào)的,接口本質(zhì)是契約,具有天然的降低耦合的作用。基于這點,我們對 Save 函數(shù)的測試也將變得十分容易,比如下面示例代碼:

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 創(chuàng)建了一個 *bytes.Buffer 類型變量 buf,由于 bytes.Buffer 實現(xiàn)了 Write 方法,進而實現(xiàn)了 io.Writer 接口,我們可以合法地將變量 buf 傳遞給 Save 函數(shù)。之后我們可以從 buf 中取出 Save 函數(shù)寫入的數(shù)據(jù)內(nèi)容與預期的數(shù)據(jù)做比對,就可以達到對 Save 函數(shù)進行單元測試的目的了。在整個測試過程中,我們不需要創(chuàng)建任何磁盤文件或建立任何網(wǎng)絡連接。

看到這里,你應該感受到了,用接口作為“關節(jié)(連接點)”的好處很多!像上面圖中展示的那樣,接口可以將各個類型水平組合(連接)在一起。通過接口的編織,整個應用程序不再是一個個孤立的“器官”,而是一幅完整的、有靈活性和擴展性的靜態(tài)骨架結構。

現(xiàn)在，我們已經(jīng)確定了接口承擔了應用骨架的“關節(jié)”角色，接下來我們來看看接口是如何演好這一角色的。

三、接口應用的幾種模式

前面已經(jīng)說了，以接口為“關節(jié)”的水平組合方式，可以將各個垂直組合出的類型“耦合”在一起，從而編織出程序靜態(tài)骨架。而通過接口進行水平組合的基本模式就是：使用接受接口類型參數(shù)的函數(shù)或方法。在這個基本模式基礎上，還有其他幾種“衍生品”。我們先從基本模式說起，再往外延伸。

3.1 基本模式

接受接口類型參數(shù)的函數(shù)或方法是水平組合的基本語法，形式是這樣的：

func YourFuncName(param YourInterfaceType)

我們套用骨架關節(jié)的概念，用這幅圖來表示上面基本模式語法的運用方法：

我們看到,函數(shù) / 方法參數(shù)中的接口類型作為“關節(jié)(連接點)”,支持將位于多個包中的多個類型與 YourFuncName 函數(shù)連接到一起,共同實現(xiàn)某一新特性。

同時,接口類型和它的實現(xiàn)者之間隱式的關系卻在不經(jīng)意間滿足了:依賴抽象(DIP)、里氏替換原則(LSP)、接口隔離(ISP)等代碼設計原則,這在其他語言中是需要很“刻意”地設計謀劃的,但對 Go 接口來看,這一切卻是自然而然的。

這一水平組合的基本模式在 Go 標準庫、Go 社區(qū)第三方包中有著廣泛應用，其他幾種模式也是從這個模式衍生的。下面我們看一下其他的各個衍生模式。

3.2 創(chuàng)建模式

Go 社區(qū)流傳一個經(jīng)驗法則：“接受接口，返回結構體（Accept interfaces, return structs）”，這其實就是一種把接口作為“關節(jié)”的應用模式。我這里把它叫做創(chuàng)建模式，是因為這個經(jīng)驗法則多用于創(chuàng)建某一結構體類型的實例。

下面是 Go 標準庫中，運用創(chuàng)建模式創(chuàng)建結構體實例的代碼摘錄：

// $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,
    }
}

我們看到，創(chuàng)建模式在 sync、log、bufio 包中都有應用。以上面 log 包的 New 函數(shù)為例，這個函數(shù)用于實例化一個 log.Logger 實例，它接受一個 io.Writer 接口類型的參數(shù)，返回 *log.Logger。從 New 的實現(xiàn)上來看，傳入的 out 參數(shù)被作為初值賦值給了 log.Logger 結構體字段 out。

創(chuàng)建模式通過接口，在 NewXXX 函數(shù)所在包與接口的實現(xiàn)者所在包之間建立了一個連接。大多數(shù)包含接口類型字段的結構體的實例化，都可以使用創(chuàng)建模式實現(xiàn)。這個模式比較容易理解，我們就不再深入了。

3.3 包裝器模式

在基本模式的基礎上，當返回值的類型與參數(shù)類型相同時，我們能得到下面形式的函數(shù)原型：

func YourWrapperFunc(param YourInterfaceType) YourInterfaceType

通過這個函數(shù)，我們可以實現(xiàn)對輸入?yún)?shù)的類型的包裝，并在不改變被包裝類型（輸入?yún)?shù)類型）的定義的情況下，返回具備新功能特性的、實現(xiàn)相同接口類型的新類型。這種接口應用模式我們叫它包裝器模式，也叫裝飾器模式。包裝器多用于對輸入數(shù)據(jù)的過濾、變換等操作。

下面就是 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 函數(shù)的包裝后，我們得到了一個具有新功能特性的 io.Reader 接口的實現(xiàn)類型，也就是 LimitedReader。這個新類型在 Reader 的語義基礎上實現(xiàn)了對讀取字節(jié)個數(shù)的限制。

接下來我們再具體看 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

我們看到，當采用經(jīng)過 LimitReader 包裝后返回的 io.Reader 去讀取內(nèi)容時，讀到的是經(jīng)過 LimitedReader 約束后的內(nèi)容，也就是只讀到了原字符串前面的 4 個字節(jié)：“hell”。

由于包裝器模式下的包裝函數(shù)（如上面的 LimitReader）的返回值類型與參數(shù)類型相同，因此我們可以將多個接受同一接口類型參數(shù)的包裝函數(shù)組合成一條鏈來調(diào)用，形式是這樣的：

YourWrapperFunc1(YourWrapperFunc2(YourWrapperFunc3(...)))

我們在上面示例的基礎上自定義一個包裝函數(shù)：CapReader，通過這個函數(shù)的包裝，我們能得到一個可以將輸入的數(shù)據(jù)轉(zhuǎn)換為大寫的 Reader 接口實現(xiàn)：

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 串在了一起形成一條調(diào)用鏈，這條調(diào)用鏈的功能變?yōu)椋航厝≥斎霐?shù)據(jù)的前四個字節(jié)并將其轉(zhuǎn)換為大寫字母。這個示例的運行結果與我們預期功能也是一致的：

HELL

3.4 適配器模式

適配器模式不是基本模式的直接衍生模式，但這種模式是后面中間件模式的前提，所以我們需要簡單介紹下這個模式。

適配器模式的核心是適配器函數(shù)類型（Adapter Function Type）。適配器函數(shù)類型是一個輔助水平組合實現(xiàn)的“工具”類型。這里我要再強調(diào)一下，它是一個類型。它可以將一個滿足特定函數(shù)簽名的普通函數(shù)，顯式轉(zhuǎn)換成自身類型的實例，轉(zhuǎn)換后的實例同時也是某個接口類型的實現(xiàn)者。

這里，我們來看一個應用 http.HandlerFunc 的例子：

func greetings(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Welcome!")
}

func main() {
    http.ListenAndServe(":8080", http.HandlerFunc(greetings))
}

我們可以看到，這個例子通過 http.HandlerFunc 這個適配器函數(shù)類型，將普通函數(shù) greetings 快速轉(zhuǎn)化為滿足 http.Handler 接口的類型。而 http.HandleFunc 這個適配器函數(shù)類型的定義是這樣的：

// $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)
}

經(jīng)過 HandlerFunc 的適配轉(zhuǎn)化后，我們就可以將它的實例用作實參，傳遞給接收 http.Handler 接口的 http.ListenAndServe 函數(shù)，從而實現(xiàn)基于接口的組合。

3.5 中間件（Middleware）

最后，我們看下中間件這個應用模式。中間件（Middleware）這個詞的含義可大可小。在 Go Web 編程中，“中間件”常常指的是一個實現(xiàn)了 http.Handler 接口的 http.HandlerFunc 類型實例。實質(zhì)上，這里的中間件就是包裝模式和適配器模式結合的產(chǎn)物。

我們來看一個例子：

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）本質(zhì)就是一個包裝函數(shù)（支持鏈式調(diào)用），但它的內(nèi)部利用了適配器函數(shù)類型（http.HandlerFunc），將一個普通函數(shù)（比如例子中的幾個匿名函數(shù)）轉(zhuǎn)型為實現(xiàn)了 http.Handler 的類型的實例。

運行這個示例，并用 curl 工具命令對其進行測試，我們可以得到下面結果：

$curl http://localhost:8080
bad auth param

$curl -H "auth:123456" localhost:8080/ 
Welcome!

從測試結果上看，中間件 authHandler 起到了對 HTTP 請求進行鑒權的作用。

四、接口使用的注意事項

盡量避免使用空接口作為函數(shù)參數(shù)類型

Go 語言之父 Rob Pike 曾說過：空接口不提供任何信息（The empty interface says nothing）。我們應該怎么理解這句話的深層含義呢？

在 Go 語言中，一方面你不用像 Java 那樣顯式聲明某個類型實現(xiàn)了某個接口，但另一方面，你又必須聲明這個接口，這又與接口在 Java 等靜態(tài)類型語言中的工作方式更加一致。

這種不需要類型顯式聲明實現(xiàn)了某個接口的方式，可以讓種類繁多的類型與接口匹配，包括那些存量的、并非由你編寫的代碼以及你無法編輯的代碼（比如：標準庫）。Go 的這種處理方式兼顧安全性和靈活性，其中，這個安全性就是由 Go 編譯器來保證的，而為編譯器提供輸入信息的恰恰是接口類型的定義。

比如我們看下面的接口：

// $GOROOT/src/io/io.go
type Reader interface {
  Read(p []byte) (n int, err error)
}

Go 編譯器通過解析這個接口定義，得到接口的名字信息以及它的方法信息，在為這個接口類型參數(shù)賦值時，編譯器就會根據(jù)這些信息對實參進行檢查。這時你可以想一下，如果函數(shù)或方法的參數(shù)類型為空接口 interface{}，會發(fā)生什么呢？

這恰好就應了 Rob Pike 的那句話：“空接口不提供任何信息”。這里“提供”一詞的對象不是開發(fā)者，而是編譯器。在函數(shù)或方法參數(shù)中使用空接口類型，就意味著你沒有為編譯器提供關于傳入實參數(shù)據(jù)的任何信息，所以，你就會失去靜態(tài)類型語言類型安全檢查的“保護屏障”，你需要自己檢查類似的錯誤，并且直到運行時才能發(fā)現(xiàn)此類錯誤。

所以，建議 Gopher 盡可能地抽象出帶有一定行為契約的接口，并將它作為函數(shù)參數(shù)類型，盡量不要使用可以“逃過”編譯器類型安全檢查的空接口類型（interface{}）。

在這方面，Go 標準庫已經(jīng)為我們作出了“表率”。全面搜索標準庫后，你可以發(fā)現(xiàn)以 interface{} 為參數(shù)類型的方法和函數(shù)少之甚少。不過，也還有，使用 interface{} 作為參數(shù)類型的函數(shù)或方法主要有兩類：

• 容器算法類，比如：container 下的 heap、list 和 ring 包、sort 包、sync.Map 等；
• 格式化 / 日志類，比如：fmt 包、log 包等。

這些使用 interface{} 作為參數(shù)類型的函數(shù)或方法都有一個共同特點，就是它們面對的都是未知類型的數(shù)據(jù)，所以在這里使用具有“泛型”能力的 interface{} 類型。

五、小結

在使用接口前一定要搞清楚自己使用接口的原因，千萬不能為了使用接口而使用接口。

接口與 Go 的“組合”的設計哲學息息相關。在 Go 語言中，組合是 Go 程序間各個部分的主要耦合方式。垂直組合可實現(xiàn)方法實現(xiàn)和接口定義的重用，更多用于在新類型的定義方面。而水平組合更多將接口作為“關節(jié)”，將各個垂直組合出的類型“耦合”在一起，從而編制出程序的靜態(tài)骨架。

通過接口進行水平組合的基本模式，是“使用接受接口類型參數(shù)的函數(shù)或方法”，在這一基本模式的基礎上，我們還了解了幾個衍生模式：創(chuàng)建模式、包裝器模式與中間件模式。此外，我們還學習了一個輔助水平組合實現(xiàn)的“工具”類型：適配器函數(shù)類型，它也是實現(xiàn)中間件模式的前提。

最后需要我們牢記的是：我們要盡量避免使用空接口作為函數(shù)參數(shù)類型。一旦使用空接口作為函數(shù)參數(shù)類型，你將失去編譯器為你提供的類型安全保護屏障。

以上就是詳解Go語言中接口應用模式或慣例介紹的詳細內(nèi)容，更多關于Go接口的資料請關注腳本之家其它相關文章！

最新評論