Go 的编程思想是什么？

[index90]

一直 OOP，换到 Go 也是用 OOP 思想，但总感觉很别扭啊。 有没有什么指引？

[zjsxwc]

我的体会是 go 可以 oop，它的结构 struct 有方法 method 与数据成员，也有 interface，于是就可以依赖注入，于是就可以处理业务复杂的项目。

[abcbuzhiming]

@yippees C#和 Java 一样的，不能多继承，多继承不是什么好设计

[cuebyte]

Go 就是有 GC 的 C 啊，不會組織項目只能說明還需要學習。

[MadbookPro]

@Yuicon #9 赞成，比如说 Context

[yippees]

@abcbuzhiming 是的，记错了。c#不能多继承。

[blless]

就没人说 Go 工程管理远比其他语言便利吗？
一门语言语法根本不能说明什么，说点其他的，写个完整项目需要啥。
首先，得有代码规范，其他语言的代码规范要么宽泛，要么约定俗成。真的要实际应用还得依赖各种第三方库，形成最佳实践。go 代码规范不说，连方法大小写，括号，缩进都规定了，工具链还自带 go vet,go fmt。其他语言要做到这样起码要有个资深项目经理，或者老程序员。直接上 go，我说省下半个项目经理不过分吧？
第二，代码仓库。go mod/go get/go list 就不说了，自带包管理,很多主流语言还是要插件才可以的。特意说一下代码仓库代码仓库，java maven, python pip,node npm,C# nuget...官方仓库当然好用，但是团队合作如果要发布到自己的代码仓库，go 绝对是最省事的，直接部署一套 git 就搞定了。这个特性加上跨平台静态编译，省掉几个运维不夸张吧？
第三，集成测试。go test /benchmark,go tool cover。不多说了，项目稳定性，健壮性基本都是靠测试用例堆起来的。
第四，debug。go pprof,trace。自带不多说了，目前已经自带火焰图了。
第五，文档。go doc。大项目必备。
大概就是这么回事，一条龙服务。其他语言目前这么完备的还没看到，rust 好像有几条已经差不多了。我反正这么用起来还是挺舒服的。

[SuperMild]

@blless Go 的工具链确实优秀，而且是语言初期就官方介入，实用性强。

[azh7138m]

@blless 不得，大部分 js 的保管理器，是支持从 git 安装依赖的，你看到 npm 这种也是支持的

[ryanking8215]

go 的 OOP，特性不多，但是基本够用。
封装：可以自定义 struct 封装数据，使用 struct 接收者的函数封装行为，类似于 class
继承：使用 mixin 的方式达到类似继承的方法
多态：使用 interface

go 的设计模式：不像有的语言库，支持单例模式或者基于委托的观察者模式，go 没有，需要自己撸，但是有了 OOP 的基本特性，也是可以实现的。另外 go 的函数是 first class, 可以适当的使用 FP 的方式简化一些设计模式的实现，例如工厂模式等。

go 的程序架构：MVC，ddd/clean architecture 都适用。

[blless]

@azh7138m 包管理想了想确实也不算太大优势，整套工具链整合才算优势吧。

[azh7138m]

@blless 我觉得不行，go 在 1.11 之前，我一个依赖，本地不存一份，就意味着，一旦他更新了，我就血崩，没有版本管理，很尴尬。还有一个项目里面可能依赖一个包多个版本的情况，也会很难处理。
go 在这些事情上提供很少的操作空间，大部分时候确实换取了开发效率的提高，可是项目一旦大起来，依赖多起来之后要怎么办呢？
rust 比 go 不知高到哪里去，cargo rustup 用起来多方便，我要安装多个 go 还不是要自己切一下目录，多尴尬啊。

[huiyifyj]

@azh7138m #51
同意，go 的包管理真的无法接受。

[blless]

@azh7138m 本地固化依赖也是正常操作吧，我们项目基本上外部包应该都是封装过后再用的。直接引入业务这样就直接耦合了，所以多个依赖 /多个版本这种操作都是可以通过项目结构封装避免的，其他语言同样也会遇到这种问题的，相对来说 Go 语言提供的接口反而比别的语言更容易封装跟解耦。
rust 我只是粗粗看了下，还没有深入，没法讨论。不过多版本兼容，多个 go 我记得也是有的，go get 就可以直接升级。跨版本兼容的时候也可以用 // +build 条件编译限定不同 go 版本。我觉得大部分场景是够用的

[feather12315]

@azh7138m #51 我学过俩周的 rust，写了一个 tun/tap 捕捉 /转发网络流量的小程序。讲道理，我觉得 rust 就不是给新手用的语言，从根本上决定了它不可能如 go 一样流行。而 go 的版本管理…狗屎

[scnace]

@azh7138m 从没有依赖版本管理 到 vendor 再到 dep 再到 现在官方强推的 mod 以及新出的 Go Team 自己托管的 go sum 验证中心 Go 不是在慢慢变得成熟吗？没有人是生来就是完美的啊 :/ （如果你是要跟风带 Rust 节奏 就当看不见我就好了

[gowk]

@abcbuzhiming 感谢这么详细的介绍，我不太明白什么是对象范式，能不能举个实例介绍一下什么是对象范式，为什么对象范式比现在的面向类的设计好用？

[wweir]

@abcbuzhiming 单冲这段介绍，必须 follow 一下。
半年前专门思考了 golang 的封装、描述世界的方式两三个月。
当时的结论是 golang 的 interface 方式描述世界的能力远继承的方式，唯一的缺点是业界对其使用方式的思考还比较欠缺。很多时候还是从继承的角度来进行封装，距离最佳实践的距离还很远。
所以看起来像是 golang 描述世界的能力很欠缺，实现不了大型应用。估计再过几年、十几年，大家（真正写业务的普通程序员）的认知够了，周边工具也完善了，也就能拿 golang 写大型单体服务了

[thuai]

@wweir dragonboat 不知道有没有二十万代码

[wweir]

@azh7138m @blless
golang 在 1.11 之后，包管理这一块依然很欠缺。而且，欠缺的不是工具，而是生态，以下这几个问题是日常踩坑：
1. 没有中心化的包下载仓库，网络、删除方面容易出问题
2. 没有中心化管理，导致大量仓库质量鱼龙混杂
3. 前些年没强调版本管理，导致大量包压根没有版本
4. 部分流行的包版本管理不规范，如：开个 v0.0.1 的版本，之后一两年年不发新版本

关于这些东西，之前专门写了个文章来进行分析：
https://wweir.cc/post/golang-%E9%A1%B9%E7%9B%AE%E7%BB%84%E7%BB%87%E5%BD%A2%E5%BC%8F%E7%9A%84%E6%BC%94%E8%BF%9B/

[wweir]

@thuai dragonboat：62979 行，同样去除非代码部分和测试代码。

PS: 之前看过几篇 paxos、raft 相关的论文，一直想看一看 dragonboat 源码的。