经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » 程序设计 » Go语言 » 查看文章
golang拾遗：嵌入类型
来源：cnblogs　　作者：apocelipes　　时间：2020/12/8 9:09:21　　对本文有异议

这里是golang拾遗系列的第三篇，前两篇可以点击此处链接跳转：

golang拾遗：为什么我们需要泛型

golang拾遗：指针和接口

今天我们要讨论的是golang中的嵌入类型（embedding types），有时候也被叫做嵌入式字段（embedding fields）。

我们将会讨论为什么使用嵌入类型，以及嵌入类型的一些“坑”。

本文索引

什么是嵌入类型

鉴于可能有读者是第一次听说这个术语，所以容我花一分钟做个简短的解释，什么是嵌入类型。

首先参考以下代码：

  1. type FileSystem struct {
  2.     MetaData []byte
  3. }
  5. func (fs *FileSystem) Read() {}
  6. func (fs *FileSystem) Write() {}
  8. type NTFS struct {
  9.     *FileSystem
  10. }
  12. type EXT4 struct {
  13.     *FileSystem
  14. }

我们有一个FileSystem类型作为对文件系统的抽象，其中包含了所有文件系统都会存在的元数据和读写文件的方法。接着我们基于此定义了Windows的NTFS文件系统和广泛应用于Linux系统中的EXT4文件系统。在这里的*FileSystem就是一个嵌入类型的字段。

一个更严谨的解释是：如果一个字段只含有字段类型而没有指定字段的名字，那么这个字段就是一个嵌入类型字段。

嵌入类型的使用

在深入了解嵌入类型之前，我们先来简单了解下如何使用嵌入类型字段。

嵌入类型字段引用

嵌入类型只有类型名而没有字段名，那么我们怎么引用它呢？

答案是嵌入类型字段的类型名会被当成该字段的名字。继续刚才的例子，如果我想要在NTFS中引用FileSystem的函数，则需要这样写：

  1. type FileSystem struct {
  2.     MetaData []byte
  3. }
  5. func (fs *FileSystem) Read() {}
  6. func (fs *FileSystem) Write() {}
  8. type NTFS struct {
  9.     *FileSystem
  10. }
  12. // fs 是一个已经初始化了的NTFS实例
  13. fs.FileSystem.Read()

要注意，指针的*只是类型修饰符，并不是类型名的一部分，所以对于形如*Type和Type的嵌入类型，我们都只能通过Type这个名字进行引用。

通过Type这个名字，我们不仅可以引用Type里的方法，还可以引用其中的数据字段：

  1. type A struct {
  2.     Age int
  3.     Name string
  4. }
  6. type B struct {
  7.     A
  8. }
  10. b := B{}
  11. fmt.Println(b.A.Age, b.A.Name)

嵌入类型的初始化

在知道如何引用嵌入类型后我们想要初始化嵌入类型字段也就易如反掌了，嵌入类型字段只是普通的匿名字段，你可以放在类型的任意位置，也就是说嵌入类型可以不必作为类型的第一个字段：

  1. type A struct {
  2.     a int
  3.     b int
  4. }
  6. type B struct {
  7.     *A
  8.     name string
  9. }
  11. type C struct {
  12.     age int
  13.     B
  14.     address string
  15. }

B和C都是合法的，如果想要初始化B和C，则只需要按字段出现的顺序给出相应的初始化值即可：

  1. // 初始化B和C
  3. b := &B{
  4.     &A{1, 2},
  5.     "B",
  6. }
  8. c := &C{
  9.     30,
  10.     B{
  11.         &A{1, 2},
  12.         "B in C",
  13.     },
  14.     "my address",
  15. }

由于我们还可以使用对应的类型名来引用嵌入类型字段，所以初始化还可以写成这样：

  1. // 使用字段名称初始化B和C
  3. b := &B{
  4.     A: &A{1, 2},
  5.     name: "B",
  6. }
  8. c := &C{
  9.     age: 30,
  10.     B: B{
  11.         A: &A{1, 2},
  12.         name: "B in C",
  13.     },
  14.     address: "my address",
  15. }

嵌入类型的字段提升

自所以会需要有嵌入类型，是因为golang并不支持传统意义上的继承，因此我们需要一种手段来把父类型的字段和方法“注入”到子类型中去。

所以嵌入类型就出现了。

然而如果我们只能通过类型名来引用字段，那么实际上的效果还不如使用一个具名字段来的方便。所以为了简化我们的代码，golang对嵌入类型添加了字段提升的特性。

什么是字段提升

假设我们有一个类型Base，它拥有一个Age字段和一个SayHello方法，现在我们把它嵌入进Drived类型中：

  1. type Base struct {
  2.     Age int
  3. }
  5. func (b *Base) SayHello() {
  6.     fmt.Printf("Hello! I'm %v years old!", b.Age)
  7. }
  9. type Drived struct {
  10.     Base
  11. }
  13. a := Drived{Base{30}}
  14. fmt.Println(a.Age)
  15. a.SayHello()

注意最后两行，a直接引用了Base里的字段和方法而无需给出Base的类型名，就像Age和SayHello是Drived自己的字段和方法一样，这就叫做“提升”。

提升是如何影响字段可见性的

我们都知道在golang中小写英文字母开头的字段和方法是包私有的，而大写字母开头的是可以在任意地方被访问的。

之所以要强调包私有，是因为有以下的代码：

  1. package main
  3. import "fmt"
  5. type a struct {
  6.     age int
  7.     name string
  8. }
  10. type data struct {
  11.     obj a
  12. }
  14. func (d *data) Print() {
  15.     fmt.Println(d.obj.age, d.obj.name)
  16. }
  18. func main(){
  19.     d := data{a{30, "hello"}}
  20.     d.Print() // 30 hello
  21. }

在同一个包中的类型可以任意操作其他类型的字段，包括那些出口的和不出口的，所以在golang中私有的package级别的。

为什么要提这一点呢？因为这一规则会影响我们的嵌入类型。考虑以下下面的代码能不能通过编译，假设我们有一个叫a的go module：

  1. // package b 位于a/b目录下
  2. package b
  4. import "fmt"
  6. type Base struct {
  7. 	A int
  8. 	b int
  9. }
  11. func (b *Base) f() {
  12. 	fmt.Println("from Base f")
  13. }
  15. // package main
  16. package main
  18. import (
  19. 	"a/b"
  20. )
  22. type Drived struct {
  23. 	*b.Base
  24. }
  26. func main() {
  27.     obj := Drived{&b.Base{}}
  28.     obj.f()
  29. }

答案是不能，会收到这样的错误：obj.f undefined (type Drived has no field or method f)。

同样，如果我们想以obj.b的方式进行字段访问也会报出一样的错误。

那如果我们通过嵌入类型字段的字段名进行引用呢？比如改成obj.Base.f()。那么我们会收获下面的报错：obj.Base.f undefined (cannot refer to unexported field or method b.(*Base).f)。

因为Base在package b中，而我们的Drived在package main中，所以我们的Drived只能获得在package main中可以访问到的字段和方法，也就是那些从package b中出口的字段和方法。因此这里的Base的f在package b以外是访问不到的。

当我们把Base移动到package main之后，就不会出现上面的问题了，因为前面说过，同一个包里的东西是彼此互相公开的。

最后关于可见性还有一个有意思的问题：嵌入字段本身受可见性影响吗？

考虑如下代码：

  1. package b
  3. type animal struct {
  4.     Name string
  5. }
  7. type Dog struct {
  8.     animal
  9. }
  11. package main
  13. import "b"
  15. func main() {
  16.     dog1 := b.Dog{} // 1
  17.     dog2 := b.Dog{b.animal{"wangwang"}} // 2
  18.     dog1.Name = "wangwang" // 3
  19. }

猜猜哪行会报错？

答案是2。有可能你会觉得3应该也会报错的，毕竟如果2不行的话那么实际上代表着我们在main里应该也不能访问到animals的Name才对，因为正常情况下首先我们要能访问animal，其次才能访问到它的Name字段。

然而你错了，决定方法提升的是具体的类型在哪定义的，而不是在哪里被调用的，因为Dog和animal在同一个包里，所以它会获得所有animal的字段和方法，而其中可以被当前包以外访问的字段和方法自然可以在我们的main里被使用。

当然，这里只是例子，在实际开发中我不推荐在非出口类型中定义可公开访问的字段，这显然是一种破坏访问控制的反模式。

提升是如何影响方法集的

方法集（method sets）是一个类型的实例可调用的方法的集合，在golang中一个类型的方法可以分为指针接收器和值接收器两种：

  1. func (v type) ValueReceiverMethod() {}
  2. func (p *type) PointerReceiverMethod() {}

而类型的实例也分为两类，普通的类型值和指向类型值的指针。假设我们有一个类型T，那么方法集的规律如下：

  • 假设obj的类型是T，则obj的方法集包含接收器是T的所有方法
  • 假设obj是*T，则obj的方法集包含接收器是T和*T的所以方法

这是来自golang language spec的定义，然而直觉告诉我们还有点小问题，因为我们使用的obj是值的时候通常也可以调用接收器是指针的方法啊？

这是因为在一个为值类型的变量调用接收器的指针类型的方法时，golang会进行对该变量的取地址操作，从而产生出一个指针，之后再用这个指针调用方法。前提是这个变量要能取地址。如果不能取地址，比如传入interface（非整数数字传入interface会导致值被复制一遍）时的值是不可取地址的，这时候就会忠实地反应方法集的确定规律：

  1. package main
  3. import "fmt"
  5. type i interface {
  6.     method()
  7. }
  9. type a struct{}
  10. func (_ *a) method() {}
  12. type b struct{}
  13. func (_ b) method() {}
  15. func main() {
  16.     var o1 i = a{} // a does not implement i (method method has pointer receiver)
  17.     var o2 i = b{}
  18.     fmt.Println(o1, o2)
  19. }

那么同样的规律是否影响嵌入类型呢？因为嵌入类型也分为指针和值。答案是规律和普通变量一样。

我们可以写一个程序简单验证下：

  1. package main
  3. import (
  4. 	"fmt"
  5. )
  7. type Base struct {
  8. 	A int
  9. 	b int
  10. }
  12. func (b *Base) PointerMethod() {}
  13. func (b Base) ValueMethod()    {}
  15. type DrivedWithPointer struct {
  16. 	*Base
  17. }
  19. type DrivedWithValue struct {
  20. 	Base
  21. }
  23. type checkAll interface {
  24. 	ValueMethod()
  25. 	PointerMethod()
  26. }
  28. type checkValueMethod interface {
  29. 	ValueMethod()
  30. }
  32. type checkPointerMethod interface {
  33. 	PointerMethod()
  34. }
  36. func main() {
  37. 	var obj1 checkAll = &DrivedWithPointer{&Base{}}
  38. 	var obj2 checkPointerMethod = &DrivedWithPointer{&Base{}}
  39. 	var obj3 checkValueMethod = &DrivedWithPointer{&Base{}}
  40. 	var obj4 checkAll = DrivedWithPointer{&Base{}}
  41. 	var obj5 checkPointerMethod = DrivedWithPointer{&Base{}}
  42. 	var obj6 checkValueMethod = DrivedWithPointer{&Base{}}
  43. 	fmt.Println(obj1, obj2, obj3, obj4, obj5, obj6)
  45. 	var obj7 checkAll = &DrivedWithValue{}
  46. 	var obj8 checkPointerMethod = &DrivedWithValue{}
  47. 	var obj9 checkValueMethod = &DrivedWithValue{}
  48. 	fmt.Println(obj7, obj8, obj9)
  50. 	var obj10 checkAll = DrivedWithValue{} // error
  51. 	var obj11 checkPointerMethod = DrivedWithValue{} // error
  52. 	var obj12 checkValueMethod = DrivedWithValue{}
  53. 	fmt.Println(obj10, obj11, obj12)
  54. }

如果编译代码则会得到下面的报错：

  1. # command-line-arguments
  2. ./method.go:50:6: cannot use DrivedWithValue literal (type DrivedWithValue) as type checkAll in assignment:
  3.         DrivedWithValue does not implement checkAll (PointerMethod method has pointer receiver)
  4. ./method.go:51:6: cannot use DrivedWithValue literal (type DrivedWithValue) as type checkPointerMethod in assignment:
  5.         DrivedWithValue does not implement checkPointerMethod (PointerMethod method has pointer receiver)

总结起来和变量那里的差不多，都是车轱辘话，所以我总结了一张图：

注意红色标出的部分。这是你会在嵌入类型中遇到的第一个坑，所以在选择使用值类型嵌入还是指针类型嵌入的时候需要小心谨慎。

提升和名字屏蔽

最后也是最重要的一点当嵌入类型和当前类型有同名的字段或方法时会发生什么？

答案是当前类型的字段或者方法会屏蔽嵌入类型的字段或方法。这就是名字屏蔽。

给一个具体的例子：

  1. package main
  3. import (
  4. 	"fmt"
  5. )
  7. type Base struct {
  8. 	Name string
  9. }
  11. func (b Base) Print() {
  12. 	fmt.Println("Base::Print", b.Name)
  13. }
  15. type Drived struct {
  16. 	Base
  17. 	Name string
  18. }
  20. func (d Drived) Print() {
  21. 	fmt.Println("Drived::Print", d.Name)
  22. }
  24. func main() {
  25. 	obj := Drived{Base: Base{"base"}, Name: "drived"}
  26. 	obj.Print() // Drived::Print drived
  27. }

在这里Drived中同名的Name和Print屏蔽了Base中的字段和方法。

如果我们需要访问Base里的字段和方法呢？只需要把Base当成一个普通字段使用即可：

  1. func (d Drived) Print() {
  2.     d.Base.Print()
  3. 	fmt.Println("Drived::Print", d.Name)
  4. }
  6. func main() {
  7. 	obj := Drived{Base: Base{"base"}, Name: "drived"}
  8.     obj.Print() 
  9.     // Output:
  10.     // Base::Print base
  11.     // Drived::Print drived
  12. }

同过嵌入类型字段的字段名访问的方法，其接收器是对于的嵌入类型，而不是当前类型，这也是为什么可以访问到Base.Name的原因。

如果我们的Drived.Print的签名和Base的不同，屏蔽也会发生。

还有另外一种情况，当我们有多个嵌入类型，且他们均有相同名字的成员时，会发生什么？

下面我们改进以下前面的例子：

  1. type Base1 struct {
  2. 	Name string
  3. }
  5. func (b Base1) Print() {
  6. 	fmt.Println("Base1::Print", b.Name)
  7. }
  9. type Base2 struct {
  10. 	Name string
  11. }
  13. func (b Base2) Print() {
  14. 	fmt.Println("Base2::Print", b.Name)
  15. }
  17. type Drived struct {
  18. 	Base1
  19. 	Base2
  20. 	Name string
  21. }
  23. func (d Drived) Print() {
  24. 	d.Base1.Print()
  25. 	fmt.Println("Drived::Print", d.Name)
  26. }
  28. func main() {
  29. 	obj := Drived{Base1: Base1{"base1"}, Base2: Base2{"base2"}, Name: "drived"}
  30. 	obj.Print()
  31. }

这样仍然能正常编译运行，所以我们再加点料，把Drived的Print注释掉，接着就会得到下面的错误：

  1. # command-line-arguments
  2. ./method.go:36:5: ambiguous selector obj.Print

如果我们再把Drived的Name也注释掉，那么报错会变成下面这样：

  1. # command-line-arguments
  2. ./method.go:37:17: ambiguous selector obj.Name

在没有发生屏蔽的情况下，Base1和Base2的Print和Name都提升到了Drived的字段和方法集里，所以在调用时发生了二义性错误。

要解决问题，加上嵌入类型字段的字段名即可：

  1. func main() {
  2. 	obj := Drived{Base1: Base1{"base1"}, Base2: Base2{"base2"}}
  3. 	obj.Base1.Print()
  4.     fmt.Println(obj.Base2.Name)
  5.     // Output:
  6.     // Base1::Print base1
  7.     // base2
  8. }

这也是嵌入类型带来的第二个坑，所以一个更有用的建议是最好不要让多个嵌入类型包含同名字段或方法。

总结

至此我们已经说完了嵌入类型的相关知识。

通过嵌入类型我们可以模仿传统oop中的继承，然而嵌入毕竟不是继承，还有许多细微的差异。

而在本文中还有一点没有被提及，那就是interface作为嵌入类型，因为嵌入类型字段只需要给出一个类型名，而我们的接口本身也是一个类型，所以可以作为嵌入类型也是顺理成章的。使用接口做为嵌入类型有不少值得探讨的内容，我会在下一篇中详细讨论。

参考

https://golang.org/ref/spec#Method_sets

原文链接：http://www.cnblogs.com/apocelipes/p/14090671.html

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Go语言热门文章

  • Golang从文件服务器获取图片显示到客户端
  • 谈谈Go语言中的内存重排
  • Golang 模块引入及表格读写业务快速实现示例
  • 创建并使用https证书
  • golang的reflection（转）
  • TICK技术栈（一）TICK技术栈介绍
  • beego解读Cache之MemoryCache
  • go语言reflect包最佳实践之struct操作（遍历、赋值与方法调用）
  • golang中gin框架接入jwt使用token验证身份
  • Golang解析、验证、修改URL之Host、Port、Path

    • Go语言推荐文章

  • Go 互斥锁 Mutex 源码分析(二)
  • golang对遍历目录操作的优化
  • 美团VS饿了么，到底谁更胜一筹？
  • 解码 xsync 的 map 实现
  • [golang]在Gin框架中使用JWT鉴权
  • Golang 依赖注入设计哲学｜12.6K 🌟 的依赖注入库 wire
  • 这么简单的问题都不会，那还面试什么！？
  • golang select 和外层的 for 搭配
  • Go语言的100个错误使用场景（61-68）｜并发实践
  • 实战：如何优雅的从 Skywalking 切换到 OpenTelemetry

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号