Go 是一門新興的語言，如果你正在使用它，很可能這不是你的第一門編程語言。

從不同的語言背景轉來，你帶來了自己的既有經驗和范式。你在以前的語言中習慣做的事情，在 Go 中可能并不是一個好的方式。

學習 Go 不僅僅是學習一種新的語法。它還涉及到學習一種新的程序思維方式。

一些理論知識

Go 創始人 Rob Pike 曾經說過：“Go 的接口并不是 Java 或 C# 接口的變種，而是更多。它們是大規模編程和適應性強的進化設計關鍵。”

圖片

正確使用接口可以帶來簡單性、可讀性和更靈活的代碼設計。（不正確使用會帶來新的災難）

以下是建議了解的基本原則 TOP3:

• 接口隔離原則：客戶端永遠不應該被迫實現它不使用的接口，或者客戶端不應該被迫依賴它們不使用的方法。
• 多態性：一段代碼根據它接收到的具體數據改變其行為。
• 里氏替換原則：如果你的代碼依賴于一個抽象，一個實現可以被另一個實現替換，而不需要改變你的代碼。

常見接口設計錯誤

1. 你創建了太多的接口

擁有過多接口的情況叫做：接口污染。當你在編寫具體類型之前就開始抽象時，就會出現這種情況。

由于無法預知需要哪些抽象，因此很容易編寫出過多的接口，而這些接口在日后要么是錯誤的，要么是無用的。

Go 創始人給出了一個很棒的指導方針幫助我們避免接口污染。如下：

不要使用接口設計，而是發現它們（Don’t design with interfaces, discover them.） —— Rob Pike

Rob 在這里指出的是：你不需要提前考慮你需要什么抽象。你可以從具體的結構體開始設計，并在設計需要時只創建接口。通過這樣做，你的代碼會有機地增長到預期的設計。

但我仍然看到人們提前創建接口，因為他們認為他們將來可能需要多個實現。

對于他們，我要說：

圖片

懶惰但要懶惰得好。創建接口的完美時機是當你真正需要它的時候，而不是當你預測你需要它的時候。

無用的接口往往只有一個實現。它們只是增加了一個額外的間接層，迫使程序員在他們實際上想要去實現時總是要通過這一層。

一個接口有一個成本：它是你在推理你的代碼時需要記住的一個新概念。正如 Djikstra 所說，一個理想的接口必須是：“一個可以絕對精確的新語義層面。”

所以在創建接口之前問問自己：你有多個接口的實現嗎？我強調了 “有”，因為 “將有” 意味著你可以預測未來，而你不能。

2. 你的方法太多了

在 PHP 項目中看到 10 個方法的接口是很典型的。在 Go 中，接口很小，標準庫中所有接口的平均方法數是 2。

“越大的接口抽象就越弱”，這是 Go 諺語之一。正如 Rob Pike 所說，這是關于接口最重要的事情，這意味著接口越小，它就越有用。

一個接口可以有的實現越多，它就越通用。如果你有一個包含大量方法的接口，就很難有多個實現。

你擁有的方法越多，接口就越具體。接口越具體，不同類型的機會就越小，它們可以顯示相同的行為。

io.Reader 和 io.Writer 就是有用接口的一個很好的例子，它們有數以百計的實現。或者是最經典的 error 接口，它非常強大，可以在 Go 中實現整個錯誤處理。

記住，你可以從其他接口組合一個接口。這里有一個例子：ReadWriteCloser 由 3 個較小的接口組成。

代碼如下：

type ReadWriteCloser interface {
    io.Reader
    io.Writer
    io.Closer
}

3. 你沒有編寫行為驅動的接口

在傳統語言中，諸如 User、Request 等名詞性接口非常常見。而在 Go 語言中，大多數接口都有后綴：Reader、Writer、Closer 等。這是因為，在 Go 中，接口暴露了行為，而它們的名稱則指向該行為。

在 Go 中定義接口時，你定義的不是 "某物是什么"，而是 "它提供了什么"-- 是 "行為"，而不是 "事物"！

這就是為什么 Go 中沒有 File 接口，但有Reader 和 Writer：這些都是行為，而 File 是實現 Reader 和 Writer 的事物。

《Effective Go》也提到了同樣的觀點：

Go 中的接口提供了一種指定對象行為的方法：如果某個東西可以做到這一點，那么它就可以用在這里。

在編寫接口時，盡量考慮動作或行為。如果你定義了一個名為 "Thing" 的接口，問問自己為什么這個 "Thing" 不是一個結構體。

4. 你在生產者端編寫接口

我經常在代碼審查中看到這種情況：很多開發者在同一個包，既寫了具體的實現，又定義了接口。

生產者定義的接口

但是，也許客戶端并不想使用生產者接口中的所有方法。請記住 "接口隔離原則" 中的一句話："不應強迫客戶端實現其不使用的方法"。

下面是一個例子：

package main

// ====== producer side

// This interface is not needed
type UsersRepository interface {
    GetAllUsers()
    GetUser(id string)
}

type UserRepository struct {
}

func (UserRepository) GetAllUsers()      {}
func (UserRepository) GetUser(id string) {}

// ====== client side

// Client only needs GetUser and
// can create this interface implicitly implemented
// by concrete UserRepository on his side
type UserGetter interface {
    GetUser(id string)
}

如果客戶端想使用生產者的所有方法，可以使用具體的結構體。因為結構體方法已經提供了這些行為。

即使客戶端想要解耦代碼并使用多種實現，他也可以在自己這邊創建一個包含所有方法的接口：

在客戶端定義的接口

由于 Go 中的接口是隱式滿足的，所以這些事情才得以實現。客戶端代碼不再需要導入某個接口并編寫實現，因為 Go 中沒有這樣的關鍵字。

如果實現與接口有相同的方法，那么實現就已經滿足了該接口，可以在客戶端代碼中使用。

5. 你正在返回接口

如果一個方法返回的是接口而不是具體的結構，那么調用該方法的所有客戶端都將被迫使用相同的抽象。

你需要讓客戶端決定他們需要什么樣的抽象，因為代碼是他們的庭院。

當你想使用結構體中的某項功能時，卻因為接口沒有公開它而無法使用，這是很煩人的。這種限制可能是有原因的，但并非總是如此。

下面是一個人為的例子：

type Shape interface {
    Area() float64
    Perimeter() float64
}

type Circle struct {
    Radius float64
}

func (c Circle) Area() float64 {
    return math.Pi * c.Radius * c.Radius
}

func (c Circle) Perimeter() float64 {
    return 2 * math.Pi * c.Radius
}

// NewCircle returns an interface instead of struct
func NewCircle(radius float64) Shape {
    return Circle{Radius: radius}
}

func main() {
    circle := NewCircle(5)

    // we lose access to circle.Radius
}

在上面的示例中，我們不僅無法訪問 circle.Radius，而且每次要訪問它時都需要在代碼中添加類型斷言：

shape := NewCircle(5)

if circle, ok := shape.(Circle); ok {
    fmt.Println(circle.Radius)
}

因此在設計上，請遵循 Postel 定律：“發送時要保守，接受時要寬松”，從方法中返回具體的結構，并選擇接受接口。

結合現實的代碼，例如原本的代碼是：

// Save writes the contents of doc to the file f.
func Save(f *os.File, doc *Document) error

但入參是 f *os.File，這并不靈活，也不便于測試。我們可以通過上面提到的接口方式，改造為如下代碼：

// Save writes the contents of doc to the supplied
// Writer.
func Save(w io.Writer, doc *Document) error

6. 你沒有驗證接口合規性

假設一個場景，你有一個導出名為 User 的類型的軟件包，你實現了 Stringer 接口。

因為出于某種業務原因，當你打印時，你不希望顯示 email 字段。需要如此實現邏輯：

package users

type User struct {
    Name  string
    Email string
}

func (u User) String() string {
    return u.Name
}

客戶端的代碼如下：

package main

import (
    "fmt"

    "pkg/users"
)

func main() {
    u := users.User{
       Name:  "腦子進煎魚了",
       Email: "xxx@gmail.com",
    }
    fmt.Printf("%s", u)
}

這將正確輸出：腦子進煎魚了。

現在，假設你進行了重構，不小心刪除或注釋了 String() 的實現，你的代碼看起來就像這樣：

package users

type User struct {
    Name  string
    Email string
}

在這種情況下，您的代碼仍然可以編譯和運行，但輸出結果將是 {腦子進煎魚了 xxx@gmail.com}。沒有任何程序反饋來提示你出現了問題。編譯器也不會報錯。

這種場景下，為了強制校驗某個類型是否實現了某個接口，我們可以這樣做：

package users

import "fmt"

type User struct {
    Name  string
    Email string
}

var _ fmt.Stringer = User{} // User implements the fmt.Stringer

func (u User) String() string {
    return u.Name
}

我們再嘗試一次。現在如果我們刪除 String() 方法，就會在構建時得到如下結果：

cannot use User{} (value of type User) as fmt.Stringer value in variable declaration: User does not implement fmt.Stringer (missing method String)

在該行中，我們試圖將一個空的 User{} 賦值給一個 fmt.Stringer類型的變量。由于 User{} 不再實現 fmt.Stringer，我們得到了程序的報錯反饋。

我們在變量名中使用了 _，因為我們并沒有真正使用它，所以不會執行真正的分配。

上面我們看到 User 實現了接口。User 和 *User 是不同的類型。因此，如果你想讓 *User 實現它，你可以這樣實現：

var _ fmt.Stringer = (*User)(nil) // *User implements the fmt.Stringer

并且通過這種實現，IDE 會顯式提示我們的方法是否有缺失。少了的話會有報錯提示：

圖片

還是非常方便的。當然，這個小技巧，不需要對每個實現接口的類型都這樣做，根據需求對于有必要強校驗的接口即可。

總結

今天這篇文章給大家介紹了六種常見的接口設計錯誤：創建了太多的接口、方法太多了、沒有編寫行為驅動的接口、在生產者端編寫接口、正在返回接口、沒有驗證接口合規性。

我還記得以前看到某個項目里，寫了個接口，20～30 個有待實現的方法。然而他就真的只是一個接口，那么多年過去了也沒有人再去實現這個接口。

當然，本文提供的很多接口優化建議，也是需要結合你的實際代碼（業務）場景去考慮的。大家各取所需，學習之即可。