kuanat

@xywanghb #72

我也是到了 70 楼的回复才意识到关键所在，你说的就是我想表达的。

Java 的接口和 Go 的接口只是有一样的名字，实际上作用完全不一样，根本不能拿来类比的。Java 的接口是用来解决多重继承问题的，而 Go 天然基于组合而非继承，接口的能力和责任范围都更大。

Java 的思维模型里，抽象（动词）设计这个行为越早越好，而且机制上鼓励你尽可能考虑易用性和扩展性，原因是后期做调整很麻烦。这让我想起了上学的时候，万物皆对象，想把整个宇宙都用对象和类描述出来。这个思路导致了 Java 在工程方面是有过度设计和复杂化倾向的，现实里 java 团队往往也比较大。

Go 的思维模型里，越简单越好，不需要考虑额外的东西。责任划分非常清晰，抽象这个行为局限在非常小的业务层面。

这中间的区别我认为可以上升到哲学层面，就是我开头提到的汉语和其他语言的区别。汉语是建立在组合的哲学上的，把全宇宙所有具象、抽象的概念都解构归纳成最基础的元素，大概只有几千个汉字。任何人学会这几千个字，就可以尝试自行描述整个世界。

换到其他语言，简单举例几个，化学、医学和植物学，每个都有自己无限衍生的词汇表，在一个领域的词汇积累是无法平移到另一个领域的（多继承失败）。

从这个意义上说，我认为以 Go/Rust 等等现代语言就是先进生产力的代表，减轻了开发者的心智负担，也就解放了生产力。

@aababc #64

没办法确定“实现”了接口。

在 Java 这种 strongly typed 语言中，这个判定过程发生在编译时，implements 就是告诉编译器做这个验证工作的。在 Go 这种 weakly typed 语言中，这个判定被推迟到运行时，如果没能真正实现，调用的那一刻会产生运行时错误。

于是 Java 的思维模型就是要先说清楚，即库和包的作者主动声明并接口化。而 Go 的思维模型是用到的时候再说，即调用方来定义到底需要什么接口（我定义的我自己当然知道谁实现了谁没实现）。

我前面举的例子可能不是特别恰当，但是由于 Go 的接口声明在调用方，而实现在上游的包和库，这个隔离或者独立已经是非常大的进步了。从各种开源项目看，引用上游依赖几乎是毫无副作用的事情。

@sagaxu #66

我在这个帖子反复讨论中突然意识到一个问题，就是 Go 的接口其实并不是等价于 Java 中的接口的。在 Go 实现泛型之前，Go 的接口承担了很大的抽象作用，而这个问题在 Java 中并不存在。

我在构思文章的时候一直很纠结，总感觉说不到重点上。现在看我更应该回答的问题是，Go 这样的设计到底带来了哪些实质的好处，而不是执着于辩论这个设计是否先进。

@leonshaw #62

经过这么一整个帖子的讨论，我越来越意识到之前的举例不恰当。

不论是 Go 还是 Java 都需要适配，区别更多是在难易程度上。

我设想了一个新例子，比如我一个已经存在的项目，实现了批量上传功能，调用方法入参是个包含 batchUpload() 方法的接口。

如果需要增加 A 作为云服务后端，而 A 的 sdk 只有单文件 put 功能，那么我适配的时候可以直接 func (a *A) batchUpload() { ... } 然后调用 a.put() 完成实现。

也就是说 Go 支持给我并没有所有权的代码里的结构体添加新的方法。换到 Java 里不能修改 A 的实现，就需要子类实现接口过渡一下。

在 Go 里 A 永远是那个 A ，而 Java 里子类和父类就要额外考虑类型兼容的问题。如果再有下游项目引用了我的包，或者需要 mock 一下做测试，Go 都是肉眼可见比 Java 简单很多。

@shinelamla #44

你说的不啰嗦就是我也感同身受，随便举几个例子。

从读的方面说，项目选型的时候有多个开源库备选，选哪个总要花很久调研。Go 在做同样的事情的时候，再复杂的项目，很快就能梳理清楚架构，了解代码质量。

我也是 Java 过来的人，写 Java 的时候我很讨厌写测试。原因是项目依赖很多都是非接口化的，真正用的时候要自己再封装一层。没有接口化的代码是很难做 mock 测试的，所以有很多测试框架使用了运行时动态生成 mock 代码的方式来解决这个问题，但是我内心还是不情愿写。

接触 Go 之后我反倒非常习惯写测试，不论依赖质量高低如何，mock 就是接口套一下的事情，代码很少。很早之前标准库想要提供 mock 的，后来废弃了，原因就是 mock 这个事情其实用不到再搞个库。还有个意外的副作用是甩锅的时候很有底气，接口内侧是我负责，外侧该找谁找谁。

所以我体会到最重要的事情是，只有机制上足够简洁便利，大家才会愿意用主动用，人性使然。大多数时间我并不想辩论“XXX 也可以”这种能不能的问题，大家都是图灵完备的换个表达方式而已，但是好不好用愿不愿意用才更重要。

@whitedroa #41

10 楼是走在路上手机回复的，感觉没说清楚，所以补了 11 楼的内容，后面的内容比较好理解一点。原意是 A/B 都是封装了对应厂商的 sdk 的实现，调用的时候是不关心具体是 A/B 哪个实例化的。

@lxdlam #45

之前走在路上手机回复了第一条，然后觉得不妥又举了代码的例子。经过反复讨论之后我觉得确实不合适，和我想表达的意思差得比较远了。

我这样重新总结一下，就用“推卸责任”这个说法，我觉得很恰当。

Duck typing 通过把类型检查推迟到运行时，达到了解耦接口与实现的目的。

在 Java 这类语言中，接口的定义和实现总是绑定在一起的。要么库的作者提前声明接口，然后给一个示例实现。要么调用方封装适配，把别人的代码封装到自己的接口里。

Go 里面把这个责任拆分了，写实现的就写实现，写接口的就写接口。都不用向对方负责。

@lxdlam #46

这个是我孤陋寡闻了。

我有个问题，可能严格来说 OCaml 更接近于 TS 那一类 structural typing 类型的语言？

@sagaxu #40

如果你认可要由使用者定义接口，那我们的立场是一致的。用到接口的时候再定义比预先设想就定义要好。

你举的例子正好就是 Go 风格接口的用法。区别在于如果你对 A/B 包的代码没有所有权的话（引入的第三方），并不能直接写 class A implements Storage 这样，所以一般要写一个子类 StorageA 然后你要手动完成 class StorageA implements Storage 内部的代码再封装一下。习惯上一般叫适配器模式吧。

编程语言在图灵完备层面是一样的，只是写法不同。这里的区别在于，Java 里面接口的实现和定义总是在一起的，或者说总是由同一个代码所有者完成的。我上面举的例子，接口定义和实现都是 A 的作者写的，你这个例子里实现和定义都是 main 的作者维护的。

在 Go 的例子里，接口和定义是分属不同的包，由不同的人实现的。