关于后端:用-Go-interface-等于什么也没说

大家好，我是煎鱼。

如果说在 Go 里要有一句与 interface{} 相干，你会想到什么？是万物皆要定义 interface，否则没法形象？

Go 谚语中认可的是：”interface{} says nothing”，也就是 interface{} 什么也没说。这指的又什么，太黑话了吧 …

明天就煎鱼和大家一起学习。

接口类型无自描述

interface{} 的第一种用法，那就是变量的数据类型申明。联合其它语言来看，一共有如下几种模式：

let i:any = 1;          // Typescript
std::any i = 1;         // C++17
Object i = 1;           // Java
var i interface{} = 1   // Go

Go 在 1.18 后，也反对了 any 关键字的申明办法，是相似 interface{} 的作用，各路语言都趋同了。

在理论编程中频繁的用接口（interface{}）类型作为变量的类型有没有问题呢？

明确的申明

当咱们在浏览 Go 代码时。如果文档、命名、、参数（含类型）是清晰的，牢靠的。咱们大概率会间接调用，明确的类型会更让咱们有”安全感“，晓得要传什么值。

如下函数签名：

func Eat(v string) {...}

当然晓得调用 Eat 函数要传 string 类型了，不是传什么 int 类型。

未知的申明

如果一个函数的参数的类型是 interface{}，咱们就会进函数内看其具体的实现，以此寻求确定性。

如下函数签名：

func Eat(v interface{}) {...}

请问变量 v 到底传什么，传 int 类型，还是 string 类型，又或是都能够？

正如谚语中所说，定义了 interface{}，是什么都没说，显然是“不大好的滋味”，这样的代码无奈自描述。程序员得翻代码或文档（文档还不肯定更新的及时）。

注：在公司真见到这种场景，该位同学猜不透，大呼绝绝子，翻代码去了。

小接口优于大接口

在业内小而集中的接口是编写弱小而灵便的 Go 代码的要害被宽泛认可。io 规范库中的 io.Reader 和 io.Writer 接口是官网认可的教科书式案例。

io.Reader：

type Reader interface {Read(p []byte) (n int, err error)
}

io.Writer：

type Writer interface {Write(p []byte) (n int, err error)
}

小接口与大接口相比，用户认知的心智和实现老本较低。

从现实情况来讲，当一个 Go 代码库中领有 6 个，甚至更多的大型接口往往只有两种实现，那就是惟一的具体实现和一个用于测试的模仿实现。

另外 io.Reader 和 io.Writer 接口并不是后期设计的，它们是起初发现的。Network、File 和其余字节解决类型须要共享相似的实现。

所以基于这些类似的诉求中，io.Reader 和 io.Writer 接口诞生了。

“最佳实际”都是实际、摸索、演变进去的。

总结

明天咱们对 Go 谚语中的：”interface{} says nothing” 进行了大抵的理解，外围的官网倡议在于：

• 接口类型，没有明确的类型自描述，会在编程、合作、文档等均带来肯定的麻烦，就跟什么都没说一样。不倡议频繁应用。

• 小接口和大接口：

  • 当一个接口定义领有 6 个或更多的接口办法时，它十分的鸡肋，个别只有本身的具体实现和测试实现。
  • 倡议多采取小接口的实现办法，认知和实现成本低。官网认可的最佳实际是 io.Reader 和 io.Writer 接口。

你感觉这些倡议靠谱吗？是否有大接口的应用教训？Go1.18 有了泛型后，泛型具备的绝对定义，是否能够解决这个问题？

文章继续更新，能够微信搜【脑子进煎鱼了】浏览，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言能够看 Go 学习地图和路线，欢送 Star 催更。

Go 图书系列

• Go 语言入门系列：初探 Go 我的项目实战
• Go 语言编程之旅：深刻用 Go 做我的项目
• Go 语言设计哲学：理解 Go 的为什么和设计思考
• Go 语言进阶之旅：进一步深刻 Go 源码

举荐浏览

• goto 语句让 Go 代码变成意大利面条？
• 太疯狂了，Go 程序说 nil 不是 nil…