Go interface 接口的最佳实践经验分享

2022-04-15 10:01:35 作者：西京刀客

go 的接口在go的编程里面用的十分频繁，尤其是空接口的使用，因为有了接口，才使得Go语言变得异常的强大，今天给大家介绍下Go interface 接口的最佳实践经验分享，感兴趣的朋友一起看看吧

Go语言-Go 接口的最佳实践

原文连接：https://blog.boot.dev/golang/golang-interfaces/

Go 中的接口允许我们暂时将不同的类型视为相同的数据类型，因为这两种类型实现相同的行为。它们是Go程序员工具箱的核心，并且经常被新的Go开发人员不正确地使用，导致代码不可读且经常有错误。

什么是Golang中的interface

In Go, an interface is a custom type that other types are able to implement, which gives Go developers a powerful way to use abstraction. Interfaces are named collections of method signatures, and when other types implement all the required methods, they implicitly implement the interface.

在 Go 中，接口是其他类型可以实现的自定义类型，这为 Go 开发人员提供了使用抽象的强大方式。接口是方法签名的集合，当其他类型实现所有需要的方法时，它们隐式地实现了接口。

例如，Go 中的errors是接口，标准error接口很简单，一个类型要被认为是error，所需要做的就是定义一个 Error ()方法，该方法不接受任何参数，并返回一个字符串。

type error interface {
    Error() string
}

错误error的简单性使得编写日志和metrics 实现更加容易。让我们定义一个表示网络问题的结构体:

type networkProblem struct {
	message string
	code    int
}

然后我们可以定义一个 Error ()方法:

func (np networkProblem) Error() string {
	return fmt.Sprintf("network error! message: %s, code: %v", np.message, np.code)
}

现在，我们可以在接受错误的任何地方使用 networkProblem struct 的实例。

func handleErr(err error) {
	fmt.Println(err.Error())
}
np := networkProblem{
	message: "we received a problem",
	code:    404,
}
handleErr(np)
// prints "network error! message: we received a problem, code: 404"

编写接口的最佳实践

编写干净的接口是困难的。坦率地说，任何时候你都在处理代码中的抽象，如果你不小心的话，简单可以很快变成复杂。让我们回顾一下保持interfaces整洁的一些经验法则。

Keep interfaces small 保持interfaces足够小
Interfaces should have no knowledge of satisfying types 接口应该没有令人满意的类型的知识
Interfaces are not classes 接口不是类

1. 保持interfaces足够小

If there is only one piece of advice that you take away from this article, make it this: keep interfaces small! Interfaces are meant to define the minimal behavior necessary to accurately represent an idea or concept.

如果您从本文中只得到了一条建议，那就是: 保持接口小一些！接口意味着定义精确表示一个想法或概念所需的最小行为。

下面是一个大型接口的标准 HTTP package的例子，它是定义最小行为的一个很好的例子:

type File interface {
    io.Closer
    io.Reader
    io.Seeker
    Readdir(count int) ([]os.FileInfo, error)
    Stat() (os.FileInfo, error)
}

Any type that satisfies the interface’s behaviors can be considered by the HTTP package as a File. This is convenient because the HTTP package doesn’t need to know if it’s dealing with a file on disk, a network buffer, or a simple []byte.

任何满足接口行为的类型都可以被 HTTP package 视为File。这很方便，因为 HTTP package 不需要知道它是在处理磁盘上的文件、还是网络缓冲区或是[]byte。

2. Interfaces Should Have No Knowledge of Satisfying Types

An interface should define what is necessary for other types to classify as a member of that interface. They shouldn’t be aware of any types that happen to satisfy the interface at design time.

接口应该定义其他类型作为该接口的成员所必需的内容。他们不应该知道在设计时为了满足接口而发生的任何类型。

例如，假设我们正在构建一个接口来描述定义汽车所必需的构成元素。

type car interface {
	Color() string
	Speed() int
	IsFiretruck() bool
}

Color() and Speed() make perfect sense, they are methods confined to the scope of a car. IsFiretruck() is an anti-pattern. We are forcing all cars to declare whether or not they are firetrucks. In order for this pattern to make any amount of sense, we would need a whole list of possible subtypes. IsPickup(), IsSedan(), IsTank()… where does it end??

Color()和Speed()非常合理，它们是限制在汽车范围内的方法。IsFiretruck ()是一个反模式。我们正在强制所有的汽车申报它们是否是消防车。为了使这个模式具有任何意义，我们需要一个可能的子类型的完整列表。IsPickup () ，IsSedan () ，IsTank () … 它在哪里结束？

Instead, the developer should have relied on the native functionality of type assertion to derive the underlying type when given an instance of the car interface. Or, if a sub-interface is needed, it can be defined as:

相反，当给定汽车接口的实例时，开发人员应该依赖于类型断言的原生功能来派生基础类型。或者，如果需要子接口，可以将其定义为:

type firetruck interface {
	car
	HoseLength() int
}

它继承了汽车所需的方法，并增加了一个额外的所需方法，使汽车一辆消防车。

3. 接口不是类

Interfaces are not classes, they are slimmer. 接口不是类，它们更小
Interfaces don’t have constructors or deconstructors that require that data is created or destroyed. 接口没有要求创建或销毁数据的构造函数或解构函数
Interfaces aren’t hierarchical by nature, though there is syntactic sugar to create interfaces that happen to be supersets of other interfaces. 接口本质上并不具有层次性，尽管在创建恰好是其他接口的超集的接口时存在语法糖
Interfaces define function signatures, but not underlying behavior. Making an interface often won’t 接口定义函数签名，但不定义底层行为。制作interface通常不会在结构方法方面不干扰您的代码。例如，如果五种类型满足错误接口，那么它们都需要自己的版本的Error() function. 函数

有关接口的更多信息

空的接口

空接口没有指定任何方法，因此 Go 中的每个类型都实现了空接口。

interface{}

It’s for this reason that developers sometimes use a map[string]interface{} to work with arbitrary JSON data, although I recommend using anonymous structs instead where possible.

出于这个原因，开发人员有时使用 map[string]interface{}来处理任意 JSON 数据，尽管我推荐在可能的情况下使用匿名结构。

Zero value of an interface

Interfaces can be nil, in fact, it’s their zero value. That’s why when we check for errors in Go, we’re always checking if err != nil, because err is an interface.

接口可以是 nil，事实上，这是它们的零值。这就是为什么当我们在 Go 中检查错误时，我们总是检查err != nil，因为 err 是一个接口。

指针上的接口

It’s a common “gotcha” in Go to implement a method on a pointer type and expect the underlying type to implement the interface, it doesn’t work like that.

在 Go 中，在指针类型上实现一个方法并期望底层类型实现接口是一个常见的“明白了”，它不是这样工作的。

type rectangle interface {
    height() int
    width() int
}

type square struct {
    length int
}

func (sq *square) width() int {
    return sq.length
}

func (sq *square) height() int {
    return sq.length
}

Though you may expect it to, in this example the square type does not implement the rectangle interface. The *square type does. If I wanted the square type to implement the rectangle interface I would just need to remove the pointer receivers.

虽然您可能希望这样做，但是在这个示例中，正方形类型不实现矩形接口。它使用的是*square。如果我想让正方形类型实现矩形接口，我只需要删除指针接收器。

type rectangle interface {
    height() int
    width() int
}

type square struct {
    length int
}

func (sq square) width() int {
    return sq.length
}

func (sq square) height() int {
    return sq.length
}

到此这篇关于Go interface 接口的最佳实践的文章就介绍到这了,更多相关Go interface 接口内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！