Golang 1.9 新特性-类型别名(Type Aliases)

类型别名是Golang 1.9引入的新特性,顾名思义类型别名是给Golang的类型提供创建别名的方法。使用的语法如下:

设计初衷

类型别名的设计初衷是为了解决代码重构时,类型在包(package)之间转移时产生的问题(参考 Codebase Refactoring (with help from Go) )。

考虑如下情景:

项目中有一个叫p1的包,其中包含一个结构体T1。随着项目的进展T1变得越来越庞大。我们希望通过代码重构将T1抽取并放入到独立的包p2,同时不希望影响现有的其他代码。这种情况下以往的go语言的功能不能很好的满足此类需求。类型别名的引入可以为此类需求提供良好的支持。

首先我们可以将T1相关的代码抽取到包p2中:

之后在p1中放入T1的别名

通过这种操作我们可以在不影响现有其他代码的前提下将类型抽取到新的包当中。现有代码依旧可以通过导入p1来使用T1。而不需要立马切换到p2,可以进行逐步的迁移。

此类重构发生不仅仅存在于上述场景还可能存在于以下场景:

  • 优化命名:如早期Go版本中的io.ByteBuffer修改为bytes.Buffer
  • 减小依赖大小:如io.EOF曾经放在os.EOF,为了使用EOF必需导入整个os包。
  • 解决循环依赖问题。

与类似语法的比较

使用已有类型声明新类型

Golang的类型声明可以使用已有的类型来创建新的类型。

T1创建的新的类型T2可以使用T1中声明的成员变量I,但是无法使用在T1上定义的方法。

我们在T1上定义了Hello方法。如果我们在T2中调用Hello将会得到错误:

可见此种方式定义的新类型只是与原类型拥有相同的数据定义,但是不共享方法。

使用匿名成员来创建类型

Golang中的结构体定义可以使用匿名成员,此时新建的结构体可以直接使用匿名成员的成员变量与方法,如同使用自身的成员变量和方法。这也是Golang实现的类似继承的机制。

这种方法看似可以替代类型别名,但是依旧存在一些问题。其中最关键的问题是虽然T1和T2看起来拥有相同的成员变量与方法,但是实际上是完全不同的类型,在有明确类型指定的地方无法混用两种类型。比如有如下函数:

SayHello传入T1类型的变量可以正常工作,但是如果传入T2类型的方法则会报错:

以上两种方法不仅在函数调用上无法混用外,也无法互相赋值、无法互相使用类型断言(Type Assertion)等。

语法细节

类型别名的使用实例如下:

通过示例可以看出我们可以在T2直接使用T1的成员变量与方法。有趣的是最后t变量本身的输出,我们得到了&main.T1{Name:"world"} 。这表明看起来我们声明了T2,但是经过编译后T2实际上会被替换为T1,他只是T1的一个字面上的别名。(看起来像C语言当中的#define T2 T1)

我们尝试为T2定义一个新方法:

T2定义新方法后我们可以看到T1也得到了同样的方法。这就进一步说明T2仅仅是T1的一个字面上的别名,两者表达的是相同的类型。

最后因为类型别名仅仅是字面上的另一个类型的别名,我们无法为包含在其他包当中的方法创建别名后为其声明新的方法,也就是下面的做法会报错:

参考文献

https://talks.golang.org/2016/refactor.article

https://github.com/golang/proposal/blob/master/design/18130-type-alias.md

发表评论:

您的电子邮件不会被公开。