总结下Go的package设计哲学

明确目的

在准备设计一个包之前,我们需要明确它的目的。
包的命名就必须明确体现其目的,而不仅仅是为了存放代码。像标准库的io,http,fmt这些包名就很好,而像util.helper,common这种命名就是反面教材。

可用性

想想使用这个包的人真正的需求,包的使用一定
要直观、简单。
在不断迭代开发、优化、完善的时候,不能让引用这个的程序出错。
防止出现需要类型断言具体类型的需求。
让单个包的代码量简化到最少,减少bug,易于掌控。

可移植性

始终追求最高可移植性。
如果包合理实用,就不要过多在意其它人的意见,没有适合所有人的完美的包。
不要让包成为单一依赖点(即所有其它包都依赖它),每个包都有自己的设计目的,可能多个包会有重复的类型,即便重复定义也不要让包成为单一依赖点,这是API设计原则。
项目结构组织的最佳实践

有两种类型的项目,一种是生成可运行程序的项目(application project),另一种是专门用于被其它项目引用的套件项目(kit project)。
对于套件项目,结构组织根据实际项目用途而定,而对于可运行程序的项目,用这样的结构:
├── cmd
├── internal
└── vendor

vendor存放依赖包,internal存放本项目内部使用的包,cmd存放可运行的程序的代码,如果该项目有多个可运行程序,可以在cmd下建子目录。

注: internal可以被编译器识别,在internal下面的包是不能被其它项目引用的。

internal下面如果有很多包,并且它们需要用到一些相同的逻辑,比如加解密、网络请求等,可以在internal中建platform目录,存放内部使用的套件包,这样的结构:
├── cmd
├── internal
│ └── platform
└── vendor

注:platform下面的包如果成熟了,在未来它们你可以将其开源变成公有的套件项目,供别人的项目引用。

关于日志输出,公有的套件项目不要打印日志,因为它是要被其它项目引用的,打印日志的逻辑应该让可运行的项目自己来决定。

来源:中战博客,欢迎分享!
标签: go,golang,Go语言实战,go目录结构