0.1、索引
https://waterflow.link/articles/1666171320273
1、概念
接口提供了一种指定对象行为的方法。 我们使用接口来创建多个对象可以实现的通用抽象。 Go 接口不同的原因在于它们是隐式的。 没有像 implements 这样的显式关键字来标记对象 A实现了接口B。
为了理解接口的强大，我们可以看下标准库中两个常用的接口：io.Reader 和 io.Writer。 io 包为 I/O 原语提供抽象。 在这些抽象中，io.Reader 从数据源读取数据，io.Writer 将数据写入目标。
io.Reader 包含一个 Read 方法：
type Reader interface {
Read(p []byte) (n int, err error)
}
io.Reader 接口的自定义实现应该接收一个字节切片p，把数据读取到p中并返回读取的字节数或错误。
io.Writer 定义了一个方法，Write：
type Writer interface {
Write(p []byte) (n int, err error)
}
io.Writer 的自定义实现应该将来自切片的数据p写入底层数据流并返回写入的字节数或错误。
因此，这两个接口都提供了基本的抽象：
-
io.Reader从一个源对象读取数据 -
io.Writer将数据写到一个目标对象
假设我们需要实现一个将一个文件的内容复制到另一个文件的函数。 我们可以创建一个特定的函数copyFile，它将使用 io.Reader 和 io.Writer 抽象创建一个更通用的函数：
package main
import (
"io"
"log"
"os"
)
func main() {
// 1 打开一个源文件
source, err := os.Open("a.txt")
if err != nil {
log.Fatal(err)
}
defer source.Close()
// 2 创建一个目标文件
dest, err := os.Create("b.txt")
if err != nil {
log.Fatal(err)
}
defer dest.Close()
// 从把源数据复制到目标
err = CopyFile(source, dest)
if err != nil {
log.Fatal(err)
}
}
// 复制
func CopyFile(source io.Reader, dest io.Writer) error {
var buffer = make([]byte, 1024)
for {
n, err := source.Read(buffer)
if err == nil {
_, err = dest.Write(buffer[:n])
if err != nil {
return err
}
}
if err == io.EOF {
_, err = dest.Write(buffer)
if err != nil {
return err
}
return nil
}
return err
}
}
- 我们利用os.Open打开一个文件，该函数返回一个*os.File句柄，*os.File 实现了 io.Reader 和 io.Writer
- 我们使用os.Create创建一个新的文件，该函数返回一个*os.File句柄
- 我们使用copyFile函数，该函数有两个参数，source为一个实现io.Reader接口的参数，dest为一个实现 io.Writer接口的参数
该函数适用于 *os.File 参数（因为 *os.File 实现了 io.Reader 和 io.Writer）以及任何其他可以实现这些接口的类型。 例如，我们可以创建自己的 io.Writer 写入数据库，并且代码将保持不变。 它增加了函数的通用性； 因此，他是可重用的，这很重要。
此外，为这个函数编写单元测试更容易，因为我们可以使用提供有用实现的字符串和字节包，而不是处理文件：
package main
import (
"bytes"
"strings"
"testing"
)
func TestCopyFile(t *testing.T) {
input := "hahahha"
source := strings.NewReader(input)
dest := bytes.NewBuffer(make([]byte, 0))
err := CopyFile(source, dest)
if err != nil {
t.Fatal(err)
}
got := dest.String()
if got != input {
t.Errorf("input is %s, got is %s, want is %s", input, got, input)
}
}
在上面例子中，source 是 *strings.Reader，而 dest 是 *bytes.Buffer。 在这里，我们在不创建任何文件的情况下测试 CopyFile ，归功于CopyFile的参数使用的是接口，只要我们参数实现了这俩个接口就可以运行单元测试。
2、什么时候使用接口
我们什么时候应该在 Go 中创建接口？ 让我们看一下通常认为接口带来价值的三个具体用例：
- 通用行为
- 解耦
- 限制行为
2.1、通用行为
在多种类型实现共同行为时使用接口。 在这种情况下，我们可以分解出接口内部的行为。 如果我们查看标准库，我们可以找到许多此类用例的示例。 例如，可以通过2个方法让共享资源变得安全：
- 给共享资源加锁
- 给共享资源释放锁
因此，sync包中添加了以下接口：
type Locker interface {
Lock()
Unlock()
}
该接口具有强大的可重用潜力，因为它包含对任何共享资源进行不同方式保护的常见行为。
我们都知道sync.Mutex是不支持锁的可重入的，但是有时我们希望同一个协程可以给资源重复上锁，而不会引起报错。因此，加锁和解锁就可以被抽象化，我们可以依赖 sync.Locker。
所以我们就可以很轻松的实现可重入锁，像下面这样：
package main
import (
"fmt"
"github.com/petermattis/goid"
"log"
"sync"
"sync/atomic"
)
type RecursiveMutex struct {
sync.Mutex
owner int64
recursion int32
}
// 1
func (m *RecursiveMutex) Lock() {
gid := goid.Get()
if atomic.LoadInt64(&m.owner) == gid {
m.recursion++
return
}
m.Mutex.Lock()
atomic.StoreInt64(&m.owner, gid)
m.recursion = 1
}
// 2
func (m *RecursiveMutex) Unlock() {
gid := goid.Get()
if atomic.LoadInt64(&m.owner) != gid {
panic(fmt.Sprintf("Wrong the owner (%d): %d!", m.owner, gid))
}
m.recursion--
if m.recursion != 0 {
return
}
atomic.StoreInt64(&m.owner, -1)
m.Mutex.Unlock()
}
func main() {
l := &RecursiveMutex{}
foo1(l)
}
func foo1(l *RecursiveMutex) {
log.Println("in foo")
l.Lock()
bar1(l)
l.Unlock()
}
func bar1(l *RecursiveMutex) {
l.Lock()
log.Println("in bar")
l.Unlock()
}
- 实现sync.Locker的Lock方法
- 实现sync.Locker的Unlock方法
2.2、解耦
如果我们依赖抽象而不是具体的实现，则可以用另一个具体实现取替换，甚至不必更改我们的代码。 这就是 里氏替换原则。
解耦的好处之一可能与单元测试有关。 假设我们要实现一个 StoreCourseware 方法来创建一个课件。 我们决定直接依赖具体实现：
// 课件模型
type Courseware struct {
id int64
}
type Store struct {
}
func (s Store) StoreCourseware(courseware Courseware) error {
// 需要走数据库
return nil
}
type CoursewareService struct {
store Store
}
func (cw CoursewareService) CreateCourseware(id int64) error {
courseware := Courseware{id: id}
return cw.store.StoreCourseware(courseware)
}
现在，如果我们想测试这个方法怎么办？ 因为 CoursewareService 依赖于实际实现来存储课件，所以我们不得不通过集成测试对其进行测试，这需要启动 MySQL 实例（除非我们使用诸如 go-sqlmock 之类的替代技术，但这不是本节要讨论的内容）。 尽管集成测试很有帮助，但这并不总是我们想要做的。 为了使我们代码有更大的灵活性，我们应该将 CoursewareService 与实际实现分离，这可以通过如下接口完成：
// 课件模型
type Courseware struct {
id int64
}
// 添加课件的一种实现
type Store struct {
}
func (s Store) StoreCourseware(courseware Courseware) error {
// 需要走数据库
return nil
}
// 添加课件的接口，只要实现接口不管走mysql还是内存
type CoursewareStorer interface {
StoreCourseware (courseware Courseware) error
}
type CoursewareService struct {
store CoursewareStorer
}
func (cw CoursewareService) CreateCourseware(id int64) error {
courseware := Courseware{id: id}
return cw.store.StoreCourseware(courseware)
}
因为现在存储客户是通过一个接口完成的，这给了我们更多的灵活性来测试我们想要的方法。 例如，我们可以：
- 通过集成测试使用具体实现
- 通过单元测试使用模拟（或任何类型的测试替身）
2.3、限制行为
假设我们实现了一个自定义配置包来处理动态配置。 我们通过一个 Config 结构保存配置，该结构还公开了两种方法：Get 和 Set。 以下是该代码的实现：
type Config struct {
rabbitmq string
cpu int
}
func (c *Config) Rabbitmq() string {
return c.rabbitmq
}
func (c *Config) SetRabbitmq(value string) {
c.rabbitmq = value
}
现在，假设Config有个cpu配置，但是在我们的代码中，我们不希望更新他，让他只读。 如果我们不想更改配置包，如何从语义上强制执行此配置是只读的？ 通过创建一个将行为限制为只读的抽象：
type ConfigCPUGetter interface {
Get() int
}
然后，在我们的代码中，我们可以依赖 ConfigCPUGetter 而不是具体的实现：
type Foo struct {
threshold ConfigCPUGetter
}
func NewFoo(threshold ConfigCPUGetter) Foo {
return Foo{threshold: threshold}
}
func (f Foo) Bar() {
threshold := f.threshold.Get()
// ...
}
在这个例子中，配置 getter 被注入到 NewFoo 工厂方法中。 它不会影响此函数的客户端，因为它仍然可以在实现 ConfigCPUGetter 时传递 Config 结构。 然后，我们只能读取 Bar 方法中的配置，不能修改它。 因此，我们还可以出于各种原因使用接口将类型限制为特定行为。
3、接口污染
在 Go 项目中过度使用接口是很常见的。也许开发人员的背景是 C# 或 Java，他们发现在具体类型之前创建接口是很自然的。然而，这不是 Go 中的工作方式。
正如我们所讨论的，接口是用来创建抽象的。当编程遇到抽象时，主要的警告是记住应该发现抽象，而不是创建抽象。这是什么意思？这意味着如果没有直接的理由，我们不应该开始在我们的代码中创建抽象。我们不应该使用接口进行设计，而是等待具体的需求。换句话说，我们应该在需要时创建接口，而不是在我们预见到可能需要它时。
如果我们过度使用接口，主要问题是什么？答案是它们使代码流更加复杂。添加无用的间接级别不会带来任何价值；它创建了一个毫无价值的抽象，使代码更难阅读、理解和推理。如果我们没有充分的理由添加接口，并且不清楚接口如何使代码变得更好，我们应该挑战这个接口的目的。为什么不直接调用实现呢？
注意当通过接口调用方法时，我们也可能会遇到性能开销。它需要在哈希表的数据结构中查找以找到接口指向的具体类型。但这在许多情况下都不是问题，因为开销很小。
总之，在我们的代码中创建抽象时我们应该小心——应该发现抽象，而不是创建抽象。对于我们软件开发人员来说，通过根据我们认为以后可能需要的东西来猜测完美的抽象级别是什么来过度设计我们的代码是很常见的。应该避免这个过程，因为在大多数情况下，它会用不必要的抽象污染我们的代码，使其阅读起来更加复杂。
我们不要试图抽象地解决问题，而是解决现在必须解决的问题。最后但同样重要的是，如果不清楚接口如何使代码变得更好，我们可能应该考虑删除它以使我们的代码更简单。
