Go接口

接口类型是由 type 和 interface 关键字定义的一组方法集合。其中，方法集合唯一确定了这个接口类型所表示的接口。

Go 语言要求接口类型声明中的方法必须是具名的，并且方法名字在这个接口类型的方法集合中是唯一的。

Go 1.14 版本以后，Go 接口类型允许嵌入的不同接口类型的方法集合存在交集，但前提是交集中的方法不仅名字要一样，它的函数签名部分也要保持一致，也就是参数列表与返回值列表也要相同，否则 Go 编译器照样会报错。

比如下面示例中 Interface3 嵌入了 Interface1 和 Interface2，但后两者交集中的 M1 方法的函数签名不同，导致了编译出错：

type Interface1 interface {
    M1()
}
type Interface2 interface {
    M1(string) 
    M2()
}

type Interface3 interface{
    Interface1
    Interface2 // 编译器报错：duplicate method M1
    M3()
}

在 Go 接口类型的方法集合中放入首字母小写的非导出方法也是合法的。如果接口类型的方法集合中包含非导出方法，那么这个接口类型自身通常也是非导出的，它的应用范围也仅局限于包内。不过，在日常实际编码过程中，我们极少使用这种带有非导出方法的接口类型。

空接口类型：如果一个接口类型定义中没有一个方法，那么它的方法集合就为空，比如下面的 EmptyInterface 接口类型：

type EmptyInterface interface {

}

这个方法集合为空的接口类型就被称为空接口类型，但通常我们不需要自己显式定义这类空接口类型，我们直接使用interface{}这个类型字面值作为所有空接口类型的代表就可以了。

go1.18 增加了 any 关键字，用以替代现在的 interface{} 空接口类型：type any = interface{}，实际上是 interface{} 的别名。

接口类型一旦被定义后，它就和其他 Go 类型一样可以用于声明变量，比如：

var err error   // err是一个error接口类型的实例变量
var r io.Reader // r是一个io.Reader接口类型的实例变量

这些类型为接口类型的变量被称为接口类型变量，如果没有被显式赋予初值，接口类型变量的默认值为 nil。如果要为接口类型变量显式赋予初值，我们就要为接口类型变量选择合法的右值。

如果一个类型 T 的方法集合是某接口类型 I 的方法集合的等价集合或超集，我们就说类型 T 实现了接口类型 I，那么类型 T 的变量就可以作为合法的右值赋值给接口类型 I 的变量。

如果一个变量的类型是空接口类型，由于空接口类型的方法集合为空，这就意味着任何类型都实现了空接口的方法集合，所以我们可以将任何类型的值作为右值，赋值给空接口类型的变量，比如下面例子：

var i interface{} = 15 // ok
i = "hello, golang" // ok
type T struct{}
var t T
i = t  // ok
i = &t // ok

空接口类型的这一可接受任意类型变量值作为右值的特性，让他成为 Go 加入泛型语法之前唯一一种具有“泛型”能力的语法元素，包括 Go 标准库在内的一些通用数据结构与算法的实现，都使用了空类型interface{}作为数据元素的类型，这样我们就无需为每种支持的元素类型单独做一份代码拷贝了。

类型断言

Go 语言还支持接口类型变量赋值的“逆操作”，也就是通过接口类型变量“还原”它的右值的类型与值信息，这个过程被称为“类型断言（Type Assertion）”。类型断言通常使用下面的语法形式：

v, ok := i.(T)

其中 i 是某一个接口类型变量，如果 T 是一个非接口类型且 T 是想要还原的类型，那么这句代码的含义就是断言存储在接口类型变量 i 中的值的类型为 T。

如果接口类型变量 i 之前被赋予的值确为 T 类型的值，那么这个语句执行后，左侧“comma, ok”语句中的变量 ok 的值将为 true，变量 v 的类型为 T，它值会是之前变量 i 的右值。如果 i 之前被赋予的值不是 T 类型的值，那么这个语句执行后，变量 ok 的值为 false，变量 v 的类型还是那个要还原的类型，但它的值是类型 T 的零值。

类型断言也支持下面这种语法形式：

v := i.(T)

但在这种形式下，一旦接口变量 i 之前被赋予的值不是 T 类型的值，那么这个语句将抛出 panic。如果变量 i 被赋予的值是 T 类型的值，那么变量 v 的类型为 T，它的值就会是之前变量 i 的右值。由于可能出现 panic，所以我们并不推荐使用这种类型断言的语法形式。

尽量定义“小接口”

接口类型的背后，是通过把类型的行为抽象成契约，建立双方共同遵守的约定，这种契约将双方的耦合降到了最低的程度。和生活工作中的契约有繁有简，签署方式多样一样，代码间的契约也有多有少，有大有小，而且达成契约的方式也有所不同。而 Go 选择了去繁就简的形式，这主要体现在以下两点上：

隐式契约，无需签署，自动生效

Go 语言中接口类型与它的实现者之间的关系是隐式的，不需要像其他语言（比如 Java）那样要求实现者显式放置“implements”进行修饰，实现者只需要实现接口方法集合中的全部方法便算是遵守了契约，并立即生效了。
更倾向于“小契约”

这点也不难理解。你想，如果契约太繁杂了就会束缚了手脚，缺少了灵活性，抑制了表现力。所以 Go 选择了使用“小契约”，表现在代码上就是尽量定义小接口，即方法个数在 1~3 个之间的接口。Go 语言之父 Rob Pike 曾说过的“接口越大，抽象程度越弱”，这也是 Go 社区倾向定义小接口的另外一种表述。

Go 对小接口的青睐在它的标准库中体现得淋漓尽致，这里我给出了标准库中一些我们日常开发中常用的接口的定义：

// $GOROOT/src/builtin/builtin.go
type error interface {
    Error() string
}

// $GOROOT/src/io/io.go
type Reader interface {
    Read(p []byte) (n int, err error)
}

// $GOROOT/src/net/http/server.go
type Handler interface {
    ServeHTTP(ResponseWriter, *Request)
}

type ResponseWriter interface {
    Header() Header
    Write([]byte) (int, error)
    WriteHeader(int)
}

上述这些接口的方法数量在 1~3 个之间，这种“小接口”的 Go 惯例也已经被 Go 社区项目广泛采用。

小接口有哪些优势？

接口越小，抽象程度越高

空接口的这个抽象对应的事物集合空间包含了 Go 语言世界的所有事物。

// 会飞的
type Flyable interface {
  Fly()
}

// 会游泳的
type Swimable interface {
  Swim()
}

// 会飞且会游泳的
type FlySwimable interface {
  Flyable
  Swimable
}

小接口易于实现和测试

小接口拥有比较少的方法，一般情况下只有一个方法。所以要想满足这一接口，我们只需要实现一个方法或者少数几个方法就可以了，这显然要比实现拥有较多方法的接口要容易得多。尤其是在单元测试环节，构建类型去实现只有少量方法的接口要比实现拥有较多方法的接口付出的劳动要少许多。
小接口表示的“契约”职责单一，易于复用组合

Go 推崇通过组合的方式构建程序。Go 开发人员一般会尝试通过嵌入其他已有接口类型的方式来构建新接口类型，就像通过嵌入 io.Reader 和 io.Writer 构建 io.ReadWriter 那样。

小接口更契合 Go 的组合思想，也更容易发挥出组合的威力。

定义小接口，可以遵循的几点

首先，别管接口大小，先抽象出接口

在定义小接口之前，我们需要先针对问题领域进行深入理解，聚焦抽象并发现接口，就像下图所展示的那样，先针对领域对象的行为进行抽象，形成一个接口集合：

初期，我们先不要介意这个接口集合中方法的数量，因为对问题域的理解是循序渐进的，在第一版代码中直接定义出小接口可能并不现实。而且，标准库中的 io.Reader 和 io.Writer 也不是在 Go 刚诞生时就有的，而是在发现对网络、文件、其他字节数据处理的实现十分相似之后才抽象出来的。并且越偏向业务层，抽象难度就越高
第二，将大接口拆分为小接口。

有了接口后，我们就会看到接口被用在了代码的各个地方。一段时间后，我们就来分析哪些场合使用了接口的哪些方法，是否可以将这些场合使用的接口的方法提取出来，放入一个新的小接口中，就像下面图示中的那样：

这张图中的大接口 1 定义了多个方法，一段时间后，我们发现方法 1 和方法 2 经常用在场合 1 中，方法 3 和方法 4 经常用在场合 2 中，方法 5 和方法 6 经常用在场合 3 中，大接口 1 的方法呈现出一种按业务逻辑自然分组的状态。这个时候我们可以将这三组方法分别提取出来放入三个小接口中，也就是将大接口 1 拆分为三个小接口 A、B 和 C。拆分后，原应用场合 1~3 使用接口 1 的地方就可以无缝替换为接口 A、B、C 了。
最后，要注意接口的单一契约职责。

那么，上面已经被拆分成的小接口是否需要进一步拆分，直至每个接口都只有一个方法呢？这个依然没有标准答案，不过你依然可以考量一下现有小接口是否需要满足单一契约职责，就像 io.Reader 那样。如果需要，就可以进一步拆分，提升抽象程度。

接口的静态特性与动态特性

接口的静态特性体现在接口类型变量具有静态类型，比如var err error中变量 err 的静态类型为 error。拥有静态类型，那就意味着编译器会在编译阶段对所有接口类型变量的赋值操作进行类型检查，编译器会检查右值的类型是否实现了该接口方法集合中的所有方法。如果不满足，就会报错：

var err error = 1 // cannot use 1 (type int) as type error in assignment: int does not implement error (missing Error method)

接口的动态特性，就体现在接口类型变量在运行时还存储了右值的真实类型信息，这个右值的真实类型被称为接口类型变量的动态类型。下面示例代码：

var err error
err = errors.New("error1")
fmt.Printf("%T\n", err)  // *errors.errorString

这个示例通过 errros.New 构造了一个错误值，赋值给了 error 接口类型变量 err，并通过 fmt.Printf 函数输出接口类型变量 err 的动态类型为 *errors.errorString。

这种“动静皆备”的特性，又带来了什么好处呢？

首先，接口类型变量在程序运行时可以被赋值为不同的动态类型变量，每次赋值后，接口类型变量中存储的动态类型信息都会发生变化，这让 Go 语言可以像动态语言（比如 Python）那样拥有使用Duck Typing（鸭子类型）的灵活性。所谓鸭子类型，就是指某类型所表现出的特性（比如是否可以作为某接口类型的右值），不是由其基因（比如 C++ 中的父类）决定的，而是由类型所表现出来的行为（比如类型拥有的方法）决定的。

type QuackableAnimal interface {
    Quack()
}

type Duck struct{}

func (Duck) Quack() {
    println("duck quack!")
}

type Dog struct{}

func (Dog) Quack() {
    println("dog quack!")
}

type Bird struct{}

func (Bird) Quack() {
    println("bird quack!")
}                         
                          
func AnimalQuackInForest(a QuackableAnimal) {
    a.Quack()             
}                         
                          
func main() {             
    animals := []QuackableAnimal{new(Duck), new(Dog), new(Bird)}
    for _, animal := range animals {
        AnimalQuackInForest(animal)
    }  
}

这个例子中，用接口类型 QuackableAnimal 来代表具有“会叫”这一特征的动物，而 Duck、Bird 和 Dog 类型各自都具有这样的特征，于是我们可以将这三个类型的变量赋值给 QuackableAnimal 接口类型变量 a。每次赋值，变量 a 中存储的动态类型信息都不同，Quack 方法的执行结果将根据变量 a 中存储的动态类型信息而定。这里的 Duck、Bird、Dog 都是“鸭子类型”，但它们之间并没有什么联系，之所以能作为右值赋值给 QuackableAnimal 类型变量，只是因为他们表现出了 QuackableAnimal 所要求的特征罢了。

与动态语言不同的是，Go 接口还可以保证“动态特性”使用时的安全性。比如，编译器在编译期就可以捕捉到将 int 类型变量传给 QuackableAnimal 接口类型变量这样的明显错误，决不会让这样的错误遗漏到运行时才被发现。

接口变量相等

// $GOROOT/src/runtime/runtime2.go
type iface struct {
    tab  *itab //存储动态类型、接口本身的信息（接口的类型信息、方法列表信息等）以及动态类型所实现的方法的信息
    data unsafe.Pointer
}

type eface struct {
    _type *_type //该接口类型变量的动态类型的信息
    data  unsafe.Pointer
}

eface 用于表示没有方法的空接口（empty interface）类型变量，也就是 interface{}类型的变量；
iface 用于表示其余拥有方法的接口 interface 类型变量。

对于空接口类型变量，只有 _type 和 data 所指数据内容一致的情况下，两个空接口类型变量之间才能划等号。另外，Go 在创建 eface 时一般会为 data 重新分配新内存空间，将动态类型变量的值复制到这块内存空间，并将 data 指针指向这块内存空间。因此我们多数情况下看到的 data 指针值都是不同的。

和空接口类型变量一样，只有 tab （类型信息）和 data 指的数据内容一致的情况下，两个非空接口类型变量之间才能划等号。

接口类型的装箱（boxing）原理

装箱（boxing）是编程语言领域的一个基础概念，一般是指把一个值类型转换成引用类型，比如在支持装箱概念的 Java 语言中，将一个 int 变量转换成 Integer 对象就是一个装箱操作。

在 Go 语言中，将任意类型赋值给一个接口类型变量也是装箱操作。接口类型的装箱实际就是创建一个 eface 或 iface 的过程。

接口类型变量的赋值本质上是一种装箱操作，装箱操作是由 Go 编译器和运行时共同完成的，有一定的性能开销，对于性能敏感的系统来说，我们应该尽量避免或减少这类装箱操作。

posted @ 2022-05-11 23:32 请务必优秀阅读(354) 评论(0) 收藏举报

刷新页面返回顶部

请务必优秀

人生的每一步路都算数，总有一天，她会盛开如繁花，惊艳你的生命～