给 Go 库作者的建议
Practical Advice for Go Library Authors by Jack Lindamood at GopherCon 2016
www.youtube.com/watch?v=5v2…
幻灯地址： go-talks.appspot.com/github.com/…
命名
包名是将来使用过程中的一部分，所以避免重复包名和结构与函数。比如
var h client.Client → var h http.Client 复制代码
context.NewContext() => context.Background() 复制代码
Object Creation
golang 没有构造函数，因此创建对象一般有两种办法:
- 默认的0值
- 单独的构造函数，NewSomething()
推荐使用默认 0 值的构造方法
在默认0值的情况下，各个方法要处理好0值，比如有些东西发现是0值后，给入一个默认值。
New() 构造函数很灵活，可以做任何事情，因此对于代码阅读上不利，意味着隐藏了很多东西。
有些库使用私有 struct，公开接口的方法，authImpl struct and Auth interface，这是反模式，不推荐使用。
不推荐使用 Singleton ，虽然标准库中大量使用了 Singleton 模式，但是 Jack 个人不喜欢这种模式。
使用高阶函数作为选项这种形式不推荐：NewSomething(WithThingA(), WithThingB())
日志
一些日志是直接打印到标准输出去，这是非常不好的设计，因为用户如果想关根本关不了。
建议
- 确定一下作为 库 是不是真的需要打印日志，是不是应该把输出日志的工作交给调用方决定？
- 如果一定需要日志，那么使用回调函数方式
- 输出日志到一个 interface
- 不要假定传进来的就是标准库的 log ，有很多选择。
- 尊重 stdout 和 stderr
- 不要使用 singleton
interface vs struct
接受 interface ，但返回的是 struct
这点和 Java 不同，Java 更倾向于所有东西都是通过 interface 操作。而 golang 不需要，golang 使用的是隐性interface。
什么时候 panic
最好都不 panic。如果非要 panic，可能最合适的地方是 init 的时候，因为刚一运行就能看到挂了，比较容易处理。但即使如此，也尽量不要 panic。
检查 error
问：我们是需要检查所有的 error 么？比如有些似乎不大容易出错。 答：需要， 特别是你说的这些不大容易出错的 ！！
我们用 error 代替了 exception，所以不要忽略这个东西。
处理的办法
- 最好的办法是 Bubble up，也就是传回调用方
-
但有的时候（比如
goroutine
) 不适合，那就：
- 做日志
- 或者增加某个计数器
什么时候应该返回错误比较合适？
- 当不满足约定
- 当需要的答案无法得到
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
