传入抽象接口，返回具体类型

发表于 2021-12

Go 接口的误用

在大多数强类型语言中，接口被用作描述一组类型共有的行为。比如：

type Auth interface {
    GetUser() (User, error)
}
type authImpl struct {
    // ...
}
func NewAuth() Auth {
    return &authImpl
}

使用接口好处多多，可以让不同模块之间更好的解藕，单元测试 mock 的时候也更加方便。Java 程序员太喜欢用接口了，以至于大部分转型成 Go 的程序员认为使用接口理所当然，似乎只要充满了接口，程序架构就上了个档次。真的是这样吗？

我们来看一个例子，假设有一个生产者接口 Thinger：

package producer

type Thinger interface { Thing() bool }

type defaultThinger struct{}
func (t defaultThinger) Thing() bool {}

func NewThinger() Thinger { return defaultThinger{} }

defaultThinger 是具体的 Thinger 生产者，这里初始化函数返回的是一个 Thinger 接口。

然后是消费者代码：

package consumer  // consumer.go

func Foo(t Thinger) {
    t.Thing()
}

消费者调用时使用的是 Thinger 接口，另外定义 mock，方便实现单元测试：

type mockThinger struct{}
func (t mockThinger) Thing() bool {}

func NewMock() Thinger { return mockThinger{} }

然而，这里接口的引入并没有让两个模块彻底解藕，这段代码隐含的问题是生产者接口的任何改动，都会传导至所有的消费者。我们仔细探讨一下。

作为消费者的函数 Foo(t Thinger)，它对接口的需求只是 Thing() 方法。作为生产者 type Thinger interface 而言，它可能面对不止一个消费者，所以一旦其他消费者有了新需求，生产者接口必须新增方法。比如：

type Thinger interface { 
    Thing() bool 
    AnotherThing() bool
}

这个方法并不是 Foo 所需的，但它也不得不为此改动代码，比如 mockThinger 类型得实现一个 AnotherThing() 才能让单测代码编译，尽管 AnotherThing() 和单测毫无关系。

Go 不像 Java 那样在语法层面有机制来确保接口和实现的强关联，可见，误用滥用 Go 的接口并不一定能彻底解藕。