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

從不同的語言背景轉(zhuǎn)來，你帶來了自己的既有經(jīng)驗(yàn)和范式。你在以前的語言中習(xí)慣做的事情，在 Go 中可能并不是一個好的方式。

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

一些理論知識

Go 創(chuàng)始人 Rob Pike 曾經(jīng)說過：“Go 的接口并不是 Java 或 C# 接口的變種，而是更多。它們是大規(guī)模編程和適應(yīng)性強(qiáng)的進(jìn)化設(shè)計(jì)關(guān)鍵?！?/p>

圖片

正確使用接口可以帶來簡單性、可讀性和更靈活的代碼設(shè)計(jì)。（不正確使用會帶來新的災(zāi)難）

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

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

常見接口設(shè)計(jì)錯誤

1. 你創(chuàng)建了太多的接口

擁有過多接口的情況叫做：接口污染。當(dāng)你在編寫具體類型之前就開始抽象時(shí)，就會出現(xiàn)這種情況。

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

Go 創(chuàng)始人給出了一個很棒的指導(dǎo)方針幫助我們避免接口污染。如下：

不要使用接口設(shè)計(jì)，而是發(fā)現(xiàn)它們（Don’t design with interfaces, discover them.） —— Rob Pike

Rob 在這里指出的是：你不需要提前考慮你需要什么抽象。你可以從具體的結(jié)構(gòu)體開始設(shè)計(jì)，并在設(shè)計(jì)需要時(shí)只創(chuàng)建接口。通過這樣做，你的代碼會有機(jī)地增長到預(yù)期的設(shè)計(jì)。

但我仍然看到人們提前創(chuàng)建接口，因?yàn)樗麄冋J(rèn)為他們將來可能需要多個實(shí)現(xiàn)。

對于他們，我要說：

圖片

懶惰但要懶惰得好。創(chuàng)建接口的完美時(shí)機(jī)是當(dāng)你真正需要它的時(shí)候，而不是當(dāng)你預(yù)測你需要它的時(shí)候。

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

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

所以在創(chuàng)建接口之前問問自己：你有多個接口的實(shí)現(xiàn)嗎？我強(qiáng)調(diào)了 “有”，因?yàn)?“將有” 意味著你可以預(yù)測未來，而你不能。

2. 你的方法太多了

在 PHP 項(xiàng)目中看到 10 個方法的接口是很典型的。在 Go 中，接口很小，標(biāo)準(zhǔn)庫中所有接口的平均方法數(shù)是 2。

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

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

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

io.Reader 和 io.Writer 就是有用接口的一個很好的例子，它們有數(shù)以百計(jì)的實(shí)現(xiàn)。或者是最經(jīng)典的 error 接口，它非常強(qiáng)大，可以在 Go 中實(shí)現(xiàn)整個錯誤處理。

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

代碼如下：

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

3. 你沒有編寫行為驅(qū)動的接口

在傳統(tǒng)語言中，諸如 User、Request 等名詞性接口非常常見。而在 Go 語言中，大多數(shù)接口都有后綴：Reader、Writer、Closer 等。這是因?yàn)椋?Go 中，接口暴露了行為，而它們的名稱則指向該行為。

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

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

《Effective Go》也提到了同樣的觀點(diǎn)：

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

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

4. 你在生產(chǎn)者端編寫接口

我經(jīng)常在代碼審查中看到這種情況：很多開發(fā)者在同一個包，既寫了具體的實(shí)現(xiàn)，又定義了接口。

生產(chǎn)者定義的接口

但是，也許客戶端并不想使用生產(chǎn)者接口中的所有方法。請記住 "接口隔離原則" 中的一句話："不應(yīng)強(qiáng)迫客戶端實(shí)現(xiàn)其不使用的方法"。

下面是一個例子：

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

如果客戶端想使用生產(chǎn)者的所有方法，可以使用具體的結(jié)構(gòu)體。因?yàn)榻Y(jié)構(gòu)體方法已經(jīng)提供了這些行為。

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

在客戶端定義的接口

由于 Go 中的接口是隱式滿足的，所以這些事情才得以實(shí)現(xiàn)。客戶端代碼不再需要導(dǎo)入某個接口并編寫實(shí)現(xiàn)，因?yàn)?Go 中沒有這樣的關(guān)鍵字。

如果實(shí)現(xiàn)與接口有相同的方法，那么實(shí)現(xiàn)就已經(jīng)滿足了該接口，可以在客戶端代碼中使用。

5. 你正在返回接口

如果一個方法返回的是接口而不是具體的結(jié)構(gòu)，那么調(diào)用該方法的所有客戶端都將被迫使用相同的抽象。

你需要讓客戶端決定他們需要什么樣的抽象，因?yàn)榇a是他們的庭院。

當(dāng)你想使用結(jié)構(gòu)體中的某項(xiàng)功能時(shí)，卻因?yàn)榻涌跊]有公開它而無法使用，這是很煩人的。這種限制可能是有原因的，但并非總是如此。

下面是一個人為的例子：

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，而且每次要訪問它時(shí)都需要在代碼中添加類型斷言：

shape := NewCircle(5)

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

因此在設(shè)計(jì)上，請遵循 Postel 定律：“發(fā)送時(shí)要保守，接受時(shí)要寬松”，從方法中返回具體的結(jié)構(gòu)，并選擇接受接口。

結(jié)合現(xiàn)實(shí)的代碼，例如原本的代碼是：

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

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

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

6. 你沒有驗(yàn)證接口合規(guī)性

假設(shè)一個場景，你有一個導(dǎo)出名為 User 的類型的軟件包，你實(shí)現(xiàn)了 Stringer 接口。

因?yàn)槌鲇谀撤N業(yè)務(wù)原因，當(dāng)你打印時(shí)，你不希望顯示 email 字段。需要如此實(shí)現(xiàn)邏輯：

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:  "腦子進(jìn)煎魚了",
       Email: "xxx@gmail.com",
    }
    fmt.Printf("%s", u)
}

這將正確輸出：腦子進(jìn)煎魚了。

現(xiàn)在，假設(shè)你進(jìn)行了重構(gòu)，不小心刪除或注釋了 String() 的實(shí)現(xiàn)，你的代碼看起來就像這樣：

package users

type User struct {
    Name  string
    Email string
}

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

這種場景下，為了強(qiáng)制校驗(yàn)?zāi)硞€類型是否實(shí)現(xiàn)了某個接口，我們可以這樣做：

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
}

我們再嘗試一次?，F(xiàn)在如果我們刪除 String() 方法，就會在構(gòu)建時(shí)得到如下結(jié)果：

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{} 不再實(shí)現(xiàn) fmt.Stringer，我們得到了程序的報(bào)錯反饋。

我們在變量名中使用了 _，因?yàn)槲覀儾]有真正使用它，所以不會執(zhí)行真正的分配。

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

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

并且通過這種實(shí)現(xiàn)，IDE 會顯式提示我們的方法是否有缺失。少了的話會有報(bào)錯提示：

圖片

還是非常方便的。當(dāng)然，這個小技巧，不需要對每個實(shí)現(xiàn)接口的類型都這樣做，根據(jù)需求對于有必要強(qiáng)校驗(yàn)的接口即可。

總結(jié)

今天這篇文章給大家介紹了六種常見的接口設(shè)計(jì)錯誤：創(chuàng)建了太多的接口、方法太多了、沒有編寫行為驅(qū)動的接口、在生產(chǎn)者端編寫接口、正在返回接口、沒有驗(yàn)證接口合規(guī)性。

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

當(dāng)然，本文提供的很多接口優(yōu)化建議，也是需要結(jié)合你的實(shí)際代碼（業(yè)務(wù)）場景去考慮的。大家各取所需，學(xué)習(xí)之即可。