如果说在 Go 里要有一句与 interface{} 相关,你会想到什么?是万物皆要定义 interface,否则没法抽象?
Go 谚语中认可的是:"interface{} says nothing",也就是 interface{} 什么也没说。这指的又什么,太黑话了吧...
今天就煎鱼和大家一起学习。
接口类型无自描述
interface{} 的第一种用法,那就是变量的数据类型声明。结合其它语言来看,一共有如下几种形式:
Go 在 1.18 后,也支持了 any 关键字的声明方法,是类似 interface{} 的作用,各路语言都趋同了。
在实际编程中频繁的用接口(interface{})类型作为变量的类型有没有问题呢?
明确的声明
当我们在阅读 Go 代码时。如果文档、命名、、参数(含类型)是清晰的,可靠的。我们大概率会直接调用,明确的类型会更让我们有 ”安全感“,知道要传什么值。
如下函数签名:
当然知道调用 Eat 函数要传 string 类型了,不是传什么 int 类型。
未知的声明
如果一个函数的参数的类型是 interface{},我们就会进函数内看其具体的实现,以此寻求确定性。
如下函数签名:
请问变量 v 到底传什么,传 int 类型,还是 string 类型,又或是都可以?
正如谚语中所说,定义了 interface{},是什么都没说,显然是 “不大好的味道”,这样的代码无法自描述。程序员得翻代码或文档(文档还不一定更新的及时)。
注:在公司真见到这种场景,该位同学猜不透,大呼绝绝子,翻代码去了。
小接口优于大接口
在 Go 的标准库中,package io 的 io.Reader 和 io.Writer 接口是官方认可的教科书式案例,小而美的接口是编写强大而灵活的 Go 代码的关键。
io.Reader:
io.Writer:
小接口与大接口相比,用户认知的心智和实现成本较低。
从现实情况来讲,当一个 Go 代码库中拥有 6 个,甚至更多的大型接口往往只有两种实现,那就是唯一的具体实现和一个用于测试的模拟实现。
另外从历史的角度来看, io.Reader 和 io.Writer 接口并不是前期设计的,它们是后来发现的。Network、File 和其他字节处理类型需要共享类似的实现,才诞生的 io.Reader 和 io.Writer 。
“最佳实践” 都是实践、探索、演变出来的。
总结
今天我们对 Go 谚语中的:"interface{} says nothing" 进行了大致的了解,内容不多,核心的官方建议在于:
- 接口类型,没有明确的类型自描述,会在编程、协作、文档等均带来一定的麻烦,就跟什么都没说一样。不建议频繁使用。
- 小接口和大接口:
当一个接口定义拥有 6 个或更多的接口方法时,它非常的鸡肋,一般只有自身的具体实现和测试实现。
建议多采取小接口的方式,认知和实现成本低。官方认可的最佳实践是 io.Reader 和 io.Writer 接口,太大的接口并没有太多的好处。
你觉得这个 Go 谚语靠谱吗?你是否有大接口的使用经验?
Go1.18 有了泛型后,泛型具有的相对定义,是否可以解决这个问题?