Go 介面的簡單指南

作為一名從 JavaScript 過渡到 Go 的開發人員，當我第一次開始學習 Go 時，我發現介面的概念具有挑戰性。
本指南旨在為處於類似情況的人提供 Go 介面的簡單解釋 - 無論您是來自 JavaScript 背景還是程式設計新手。

目標是展示 Go 介面的強大功能和靈活性，同時提供實用的見解。在本文結束時，我希望您能夠充分了解如何在 Go 專案中有效地使用介面。

 

概述

讓我們從 Go 退後一步，用一個簡單的類比來從高層次上理解什麼是介面。

想像一下我們生活在一個沒有 Uber、Lyft 或任何共乘服務的世界。
有一個名叫托尼的人，擁有各種類型的車輛，包括汽車、卡車和飛機。他想知道，「我怎麼能充分利用所有這些車輛？」

同時，蒂娜是一名銷售員，她的工作需要經常出差。她不喜歡開車，也沒有駕照，所以她通常會搭乘計程車。然而，隨著她的升職，她的日程變得更加忙碌和充滿活力，出租車有時無法滿足她的需求。

讓我們看看蒂娜週一到週三的行程：

• 週一：她需要在下午 2 點之前到達客戶 A 的辦公室，並且由於下午 1 點有一個重要會議，因此必須在行程中使用筆記型電腦。
• 星期二：她必須在下午 5 點前到達客戶 B 的辦公室。通勤時間大約2小時，所以她需要一輛車，讓她可以躺下來小睡。
• 週三：她需要在上午 10 點前到達機場，帶著大量行李，需要一輛寬敞的車輛。

有一天，蒂娜發現托尼有好幾種不同類型的車輛，她可以根據自己的需求選擇最合適的。

在這種情況下，每次蒂娜想去某個地方，她都必須拜訪托尼並聽他解釋所有技術細節，然後再選擇合適的汽車。不過，蒂娜並不關心這些技術細節，也不需要知道。她只是需要一輛符合她要求的車。

這是一個簡單的圖表，說明了此場景中蒂娜和托尼之間的關係：
正如我們所見，蒂娜直接詢問托尼。換句話說，蒂娜依賴托尼，因為她需要汽車時需要直接聯繫他。

 

為了讓蒂娜的生活更輕鬆，她與托尼簽訂了一份合同，該合同本質上是對汽車的要求清單。然後托尼將根據此列表選擇最合適的汽車。
在此範例中，包含一系列要求的合約有助於蒂娜抽像出汽車的細節，只專注於她的要求。 Tina 需要做的就是在合約中明確要求，Tony 就會為她選擇最合適的車。

我們可以用這張圖進一步說明這個場景中的關係：
蒂娜現在可以使用合約來獲得她需要的汽車，而不是直接詢問托尼。在這種情況下，她不再依賴托尼了；她不再依賴托尼了。相反，她依賴合約。合約的主要目的是抽象化汽車的細節，因此蒂娜不需要知道汽車的具體細節。她只需要知道這輛車滿足她的要求。

從這張圖中，我們可以辨識出以下特徵：

• 合約由Tina定義；由她決定她需要什麼要求。
• 合約充當托尼和蒂娜之間的中間人。他們並不直接相互依賴；相反，他們取決於合約。
  • 如果托尼停止提供服務，蒂娜可以與其他人使用相同的合約。
• 可能有多輛車滿足相同的要求
  • 例如，特斯拉 Model S 和賓士 S-Class 都可以滿足 Tina 的要求。

我希望這張圖對您有意義，因為理解它是掌握介面概念的關鍵。類似的圖表將出現在以下各節中，強化這個重要概念。

 

什麼是介面？

在前面的範例中，包含需求清單的合約正是 Go 中的介面。

1. 合約幫助蒂娜抽象化汽車的細節，只關注她的要求。
   • 介面抽象化了實作的細節，只關注行為。
2. 合約是由一系列要求定義的。
   • 介面由方法簽章清單定義。
3. 任何滿足要求的汽車都稱為執行合約。
   • 任何實作介面中指定的所有方法的類型稱為實作該介面。
4. 合約由消費者擁有（在本例中為蒂娜）
   • 介面由使用它的人（呼叫者）擁有
5. 合約充當蒂娜和托尼之間的中間人
   • 介面充當呼叫者與實作者之間的中間人
6. 可能有多輛車滿足相同的要求
   • 一個介面可能有多種實作

Go 與許多其他語言不同的關鍵特性是它使用隱式介面實作。這意味著您不需要明確聲明類型實作介面。只要一個類型定義了介面所需的所有方法，它就會自動實作該介面。

在 Go 中使用介面時，請務必注意它僅提供行為列表，而不提供詳細實作。介面定義了類型應該具有哪些方法，而不是它們應該如何運作。

 

簡單的例子

讓我們透過一個簡單的範例來說明 Go 中的介面如何運作。

首先，我們定義一個 Car 介面：

type Car interface {
    Drive()
}

這個簡單的 Car 介面有一個方法 Drive()，它不接受任何參數，也不回傳任何內容。任何具有具有此確切簽章的 Drive() 方法的類型都被視為實作了 Car 介面。

現在，讓我們建立一個實作 Car 介面的 Tesla 類型：

type Tesla struct{}

func (t Tesla) Drive() {
    println("driving a tesla")
}

Tesla 類型實作了 Car 接口，因為它有一個 Drive() 方法，其簽章與介面中定義的相同。

為了示範如何使用此接口，讓我們建立一個接受任何 Car 的函數：

func DriveCar(c Car) {
    c.Drive()
}

func main() {
    t := Tesla{}
    DriveCar(t)
}
/*
Output:
driving a tesla
*/

此程式碼證明 Tesla 類型實作了 Car 接口，因為我們可以將 Tesla 值傳遞給 DriveCar 函數，該函數接受任何 Car。
注意：您可以在此存儲庫中找到完整的程式碼。

了解 Tesla 隱式實作 Car 介面非常重要。沒有像 Tesla struct 類型實作 Car 介面那樣的明確聲明。相反，Go 識別 Tesla 實作 Car 只是因為它有一個具有正確簽名的 Drive() 方法。

讓我們用圖來形象化一下 Tesla 類型和 Car 介面之間的關係：
此圖說明了 Tesla 類型和 Car 介面之間的關係。請注意，Car 介面不了解 Tesla 類型的任何資訊。它不關心哪種類型正在實現它，也不需要知道。

我希望這個例子有助於闡明Go中介面的概念。如果您想知道在這個簡單場景中使用介面的實際好處，請不要擔心。我們將在下一節中探討更複雜情況下介面的強大功能和靈活性。

 

用例

在本節中，我們將探討一些實際範例，以了解為何介面有用。

多態性

介面之所以如此強大，是因為它們能夠在 Go 中實現多態性。
多態性是物件導向程式設計中的一個概念，它允許我們以相同的方式處理不同類型的物件。簡單來說，多態只是「具有多種形式」的一個花俏的字眼。
在 Go 世界中，我們可以將多型視為「一個接口，多個實作」。

讓我們透過一個例子來探討這個概念。想像一下，我們想要建立一個簡單的 ORM（物件關係映射），它可以與不同類型的資料庫一起使用。我們希望客戶端能夠輕鬆地從資料庫中插入、更新和刪除數據，而不必擔心特定的查詢語法。
對於這個例子，假設我們目前只支援 mysql 和 postgres，並且我們將只專注於插入操作。最終，我們希望客戶像這樣使用我們的 ORM：

conn := sql.Open("mysql", "root:root@tcp(127.0.0.1:3306)/test")
orm := myorm.New(&myorm.MySQL{Conn: conn})
orm.Insert("users", user)

 

首先，讓我們看看如何在不使用介面的情況下實現這一目標。
我們先定義 MySQL 和 Postgres 結構，每個結構都有一個 Insert 方法：

type MySQL struct {
    Conn *sql.DB
}

func (m *MySQL) Insert(table string, data map[string]interface{}) error {
    // insert into mysql using mysql query
}

type Postgres struct {
    Conn *sql.DB
}

func (p *Postgres) Insert(table string, data map[string]interface{}) error {
    // insert into postgres using postgres query
}

接下來，我們將定義一個帶有驅動程式欄位的 ORM 結構：

type ORM struct {
    db any
}

The ORM struct will be used by the client. We use the any type for the driver field because we can't determine the specific type of the driver at compile time.

Now, let's implement the New function to initialize the ORM struct:

func New(db any) *ORM {
    return &ORM{db: db}
}

Finally, we'll implement the Insert method for the ORM struct:

func (o *ORM) Insert(table string, data map[string]interface{}) error {
    switch d := o.db.(type) {
    case MySQL:
        return d.Insert(table, data)
    case Postgres:
        return d.Insert(table, data)
    default:
        return fmt.Errorf("unsupported database driver")
    }
}

We have to use a type switch (switch d := o.db.(type)) to determine the type of the driver because the db field is of type any.

While this approach works, it has a significant drawback: if we want to support more database types, we need to add more case statements. This might not seem like a big issue initially, but as we add more database types, our code becomes harder to maintain.

 

Now, let's see how interfaces can help us solve this problem more elegantly.
First, we'll define a DB interface with an Insert method:

type DB interface {
    Insert(table string, data map[string]interface{}) error
}

Any type that has an Insert method with this exact signature automatically implements the DB interface.
Recall that our MySQL and Postgres structs both have Insert methods matching this signature, so they implicitly implement the DB interface.

Next, we can use the DB interface as the type for the db field in our ORM struct:

type ORM struct {
    db DB
}

Let's update the New function to accept a DB interface:

func New(db DB) *ORM {
    return &ORM{db: db}
}

Finally, we'll modify the Insert method to use the DB interface:

func (o *ORM) Insert(table string, data map[string]interface{}) error {
    return o.db.Insert(table, data)
}

Instead of using a switch statement to determine the database type, we can simply call the Insert method of the DB interface.

Now, clients can use the ORM struct to insert data into any supported database without worrying about the specific implementation details:

// using mysql
conn := sql.Open("mysql", "root:root@tcp(127.0.0.1:3306)/test")
orm := myorm.New(&myorm.MySQL{Conn: conn})
orm.Insert("users", user)

// using postgres
conn = sql.Open("postgres", "user=pqgotest dbname=pqgotest sslmode=disable")
orm = myORM.New(&myorm.Postgres{Conn: conn})
orm.Insert("users", user)

With the DB interface, we can easily add support for more database types without modifying the ORM struct or the Insert method. This makes our code more flexible and easier to extend.

Consider the following diagram to illustrate the relationship between the ORM, MySQL, Postgres, and DB interfaces:
In this diagram, the ORM struct depends on the DB interface, and the MySQL and Postgres structs implement the DB interface. This allows the ORM struct to use the Insert method of the DB interface without knowing the specific implementation details of the MySQL or Postgres structs.

This example demonstrates the power of interfaces in Go. We can have one interface and multiple implementations, allowing us to write more adaptable and maintainable code.

Note: You can find the complete code in this repository.

 

Making testing easier

Let's consider an example where we want to implement an S3 uploader to upload files to AWS S3. Initially, we might implement it like this:

type S3Uploader struct {
    client *s3.Client
}

func NewS3Uploader(client *s3.Client) *S3Uploader {
    return &S3Uploader{client: client}
}

func (s *S3Uploader) Upload(ctx context.Context, bucketName, objectKey string, data []byte) error {
    _, err := s.client.PutObject(ctx, &s3.PutObjectInput{
        Bucket: aws.String(bucketName),
        Key:    aws.String(objectKey),
        Body:   bytes.NewReader(data),
    })

    return err
}

In this example, the client field in the S3Uploader struct is type *s3.Client, which means the S3Uploader struct is directly dependent on the s3.Client.
Let's visualize this with a diagram:
While this implementation works fine during development, it can pose challenges when we're writing unit tests. For unit testing, we typically want to avoid depending on external services like S3. Instead, we'd prefer to use a mock that simulates the behavior of the S3 client.

This is where interfaces come to the rescue.

We can define an S3Manager interface that includes a PutObject method:

type S3Manager interface {
    PutObject(ctx context.Context, params *s3.PutObjectInput, optFns ...func(*s3.Options)) (*s3.PutObjectOutput, error)
}

Note that the PutObject method has the same signature as the PutObject method in s3.Client.

Now, we can use this S3Manager interface as the type for the client field in our S3Uploader struct:

type S3Uploader struct {
    client S3Manager
}

Next, we'll modify the NewS3Uploader function to accept the S3Manager interface instead of the concrete s3.Client:

func NewS3Uploader(client S3Manager) *S3Uploader {
    return &S3Uploader{client: client}
}

With this implementation, we can pass any type that has a PutObject method to the NewS3Uploader function.

For testing purposes, we can create a mock object that implements the S3Manager interface:

type MockS3Manager struct{}

func (m *MockS3Manager) PutObject(ctx context.Context, params *s3.PutObjectInput, optFns ...func(*s3.Options)) (*s3.PutObjectOutput, error) {
    // mocking logic
    return &s3.PutObjectOutput{}, nil
}

We can then pass this MockS3Manager to the NewS3Uploader function when writing unit testing.

mockUploader := NewS3Uploader(&MockS3Manager{})

This approach allows us to test the Upload method easily without actually interacting with the S3 service.

After using the interface, our diagram looks like this:
In this new structure, the S3Uploader struct depends on the S3Manager interface. Both s3.Client and MockS3Manager implement the S3Manager interface. This allows us to use s3.Client for the real S3 service and MockS3Manager for mocking during unit tests.

As you might have noticed, this is also an excellent example of polymorphism in action.

Note: You can find the complete code in this repository.

 

Decoupling

In software design, it's recommended to decouple dependencies between modules. Decoupling means making the dependencies between modules as loose as possible. It helps us develop software in a more flexible way.

To use an analogy, we can think of a middleman sitting between two modules:
In this case, Module A depends on the middleman, instead of directly depending on Module B.

You might wonder, what's the benefit of doing this?
Let's look at an example.

Imagine we're building a web application that takes an ID as a parameter to get a user's name. In this application, we have two packages: handler and service.
The handler package is responsible for handling HTTP requests and responses.
The service package is responsible for retrieving the user's name from the database.

Let's first look at the code for the handler package:

package handler

type Handler struct {
    // we'll implement MySQLService later
    service service.MySQLService
}

func (h *Handler) GetUserName(w http.ResponseWriter, r *http.Request) {
    id := r.URL.Query().Get("id")

    if !isValidID(id) {
        http.Error(w, "Invalid user ID", http.StatusBadRequest)
        return
    }

    userName, err := h.service.GetUserName(id)
    if err != nil {
        http.Error(w, fmt.Sprintf("Error retrieving user name: %v", err), http.StatusInternalServerError)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(userName)
}

This code is straightforward. The Handler struct has a service field. For now, it depends on the MySQLService struct, which we'll implement later. It uses h.service.GetUserName(id) to get the user's name. The handler package's job is to handle HTTP requests and responses, as well as validation.

Now, let's look at the service package:

package service

type MySQLService struct {
    sql *sql.DB
}

func NewMySQLService(sql *sql.DB) *MySQLService {
    return &MySQLService{sql: sql}
}

func (s *MySQLService) GetUserName(id string) (string, error) {
    // get user name from database
}

Here, the MySQLService struct has an sql field, and it retrieves the user's name from the database.

In this implementation, the Handler struct is directly dependent on the MySQLService struct:
This might not seem like a big deal at first, but if we want to switch to a different database, we'd have to modify the Handler struct to remove the dependency on the MySQLService struct and create a new struct for the new database.
This violates the principle of decoupling. Typically, changes in one package should not affect other packages.

 

To fix this problem, we can use an interface.
We can define a Service interface that has a GetUserName method:

type Service interface {
    GetUserName(id string) (string, error)
}

We can use this Service interface as the type of the service field in the Handler struct:

package handler

type Service interface {
    GetUserName(id string) (string, error)
}

type Handler struct {
    service Service // now it depends on the Service interface
}

func (h *Handler) GetUserName(w http.ResponseWriter, r *http.Request) {
    // same as before

    // Get the user from the service
    user, err := h.service.GetUserName(id)
    if err != nil {
        http.Error(w, "Error retrieving user: "+err.Error(), http.StatusInternalServerError)
        return
    }

    // same as before
}

In this implementation, the Handler struct is no longer dependent on the MySQLService struct. Instead, it depends on the Service interface:
In this design, the Service interface acts as a middleman between Handler and MySQLService.
For Handler, it now depends on behavior, rather than a concrete implementation. It doesn't need to know the details of the Service struct, such as what database it uses. It only needs to know that the Service has a GetUserName method.

When we need to switch to a different database, we can just simply create a new struct that implements the Service interface without changing the Handler struct.

When designing code structure, we should always depend on behavior rather than implementation.
It's better to depend on something that has the behavior you need, rather than depending on a concrete implementation.

Note: You can find the complete code in this repository.

 

Working With the Standard Library

As you gain more experience with Go, you'll find that interfaces are everywhere in the standard library.
Let's use the error interface as an example.

In Go, error is simply an interface with one method, Error() string:

type error interface {
    Error() string
}

This means that any type with an Error method matching this signature implements the error interface. We can leverage this feature to create our own custom error types.

Suppose we have a function to log error messages:

func LogError(err error) {
    log.Fatal(fmt.Errorf("received error: %w", err))
}

While this is a simple example, in practice, the LogError function might include additional logic, such as adding metadata to the error message or sending it to a remote logging service.

Now, let's define two custom error types, OrderError and PaymentDeclinedError. These have different fields, and we want to log them differently:

// OrderError represents a general error related to orders
type OrderError struct {
    OrderID string
    Message string
}

func (e OrderError) Error() string {
    return fmt.Sprintf("Order %s: %s", e.OrderID, e.Message)
}

// PaymentDeclinedError represents a payment failure
type PaymentDeclinedError struct {
    OrderID string
    Reason  string
}

func (e PaymentDeclinedError) Error() string {
    return fmt.Sprintf("Payment declined for order %s: %s", e.OrderID, e.Reason)
}

Because both OrderError and PaymentDeclinedError have an Error method with the same signature as the error interface, they both implement this interface. Consequently, we can use them as arguments to the LogError function:

LogError(OrderError{OrderID: "123", Message: "Order not found"})
LogError(PaymentDeclinedError{OrderID: "123", Reason: "Insufficient funds"})

This is another excellent example of polymorphism in Go: one interface, multiple implementations. The LogError function can work with any type that implements the error interface, allowing for flexible and extensible error handling in your Go programs.

Note: You can find the complete code in this repository.

 

Summary

In this article, we've explored the concept of interfaces in Go, starting with a simple analogy and gradually moving to more complex examples.

Key takeaways about Go interfaces:

• They are all about abstraction
• They are defined as a set of method signatures
• They define behavior without specifying implementation details
• They are implemented implicitly (no explicit declaration needed)

I hope this article has helped you gain a better understanding of interfaces in Go.

 

Reference

• Learning Go: An Idiomatic Approach to Real-World Go Programming
• 100 Go Mistakes and How to Avoid Them
• Golang Interfaces Explained

 

As I'm not an experienced Go developer, I welcome any feedback. If you've noticed any mistakes or have suggestions for improvement, please leave a comment. Your feedback is greatly appreciated and will help enhance this resource for others.

以上是Go 介面的簡單指南的詳細內容。更多資訊請關注PHP中文網其他相關文章！