Go中面向包的设计

• 前言

• 链接

• 历史

• 语言机制

• 包的设计哲学

• 项目结构

• 验证

• 验证包的位置

• 验证依赖项

• 验证正在实施的策略

• 验证接受/返回数据的方式

• 验证如何处理错误

• 验证测试

• 验证recover和panic

前言

文章翻译自：https://github.com/ardanlabs/gotraining/tree/master/topics/go/design/packaging，属于由于gotraining系列的design/packaging篇，本人翻译水平，觉得翻译不当之处烦请指出。谢谢。

面向包的设计允许开发人员确定一个包在Go项目中的位置，并且该包必须遵守设计准则。它定义了什么是Go项目以及Go项目是如何构建起来的。最后，它增强了团队成员之间的沟通交流，促进了整洁的包设计和项目架构。

链接

可以参考阅读下面文章

包设计理念

• Design Philosophy On Packaging^[1] - William Kennedy

面向包设计

• Package Oriented Design^[2] - William Kennedy

历史

在2000年 Mihai Budiu 对 Brian Kernighan 的采访中，Brian 被问到以下问题:

“Can you tell us about the worse features of C, from your point of view”?

“从你的角度来看，你能告诉我们 c 语言最糟糕的特性是什么吗?”？

以下是Brian的回答:

I think that the real problem with C is that it doesn’t give you enough mechanisms for structuring really big programs, for creating "firewalls" within programs so you can keep the various pieces apart. It’s not that you can’t do all of these things, that you can’t simulate object-oriented programming or other methodology you want in C. You can simulate it, but the compiler, the language itself isn’t giving you any help.”

我认为 c 语言的真正问题在于它没有提供足够的机制来构造真正的大型程序，在程序中创建“防火墙”，这样就可以将各个部分分开。并不是说你不能做所有这些事情，也不是说你不能在 c 语言中模拟面向对象程序设计或者其他你想要的方法。你可以模拟它，但是编译器，语言本身不会给你任何帮助。

语言机制

• 直接使用包与我们学习如何用其他语言组织源代码相冲突
• 在其他语言中，包的设计是一种可以选择使用或忽略的特性
• 您可以将包的设计看作是在源代码树上应用微服务的思想
• 所有包都是“ first class”，唯一的层次结构是在项目的源代码树中定义的内容
• 需要有一种方式将包的一部分“暴露”给外面
• 两个软件包不能相互交叉引入。引入是单向的。

包的设计哲学

• 为了达到目的，包是需要提供其他使用的，而不是包含
• 包的命名必须带有描述它所提供的内容的意图
• 包决不能成为各种不同问题的倾倒场
• 为了便于使用，包必须以使用者为中心来设计封装
• 包必须是直观的和简单的使用
• 包必须尊重它们对资源和性能的影响
• 包必须保护用户的应用程序不受级联更改带来的影响
• 包必须防止对具体类型断言的需要
• 包必须减少、最小化和简化其代码库
• 为了便于移植，包的设计必须考虑到可重用性
• 包必须追求最高级别的可移植性
• 包必须减少设置策略，当它是合理的且实用
• 不能成为单一的依赖点

项目结构

Kit                     Application

├── CONTRIBUTORS        ├── cmd/
├── LICENSE             ├── internal/
├── README.md           │   └── platform/
├── cfg/                └── vendor/
├── examples/
├── log/
├── pool/
├── tcp/
├── timezone/
├── udp/
└── web/

• vendor/

  vendor文件夹的比较好的参考文档可以在 Daniel Theophanes 的 Gopher Academy 文章 Understanding and using the vendor folder^[3]中找到。为了这篇文章的目的，第三方软件包的所有源代码都需要转移(或复制)到vendor文件夹中。包括将从公司 Kit 项目中使用的包。也会将 Kit 项目中的软件包视为第三方软件包。

• cmd/

  cmd/这个项目拥有的所有程序都在cmd/文件夹下。cmd/下的文件夹总是会为将要生成的每个程序命名。使用程序文件夹末尾的字母 d 表示它为守护进程。每个文件夹都有一个包含main包的相匹配的源代码文件。

• internal/

  需要由项目中的多个程序导入的internal/包属于internal/文件夹。使用internal/这个名称的一个好处是，项目从编译器那里得到了额外的保护。这个项目之外的任何包都不能从internal/导入包。因此，这些软件包只属于这个项目的内部。

• internal/platform/

  基础的但对于项目来说是特定的它会归为internal/platform/ 文件夹。这些包可以为数据库、身份验证甚至序列化处理等提供支持。

验证

面向包设计的一个重要方面是去验证包设计的能力。这是可能的，因为根据包在项目中的位置与包相关联的准则。有七个验证步骤可帮助你识别设计问题。

验证包的位置

• Kit
• 为现有不同项目提供基本支持的软件包
• 日志、配置或网络功能
• cmd/
• 为正在构建的特定程序提供支持的包
• 启动，关闭和配置
• internal/
• 为项目拥有的不同程序提供支持的包
• CRUD,服务或业务逻辑
• internal/platform/
• 为项目提供内部基本支持的包
• 数据库、身份验证或序列化处理

验证依赖项

• All
• 要质疑当前这些软件包的设计选择
• 如果合理的话，将包移动到要导入包的源代码树中
• 使用source tree来显示依赖关系
• 验证每个依赖项的成本/收益
• 为了共用现有类型要质疑导入
• 对同一级别其他包的导入问题
• 如果一个包想要导入另一个同级别的包:
• internal/
• cmd/
• 不能导入来自这些位置的包:
• internal/platform/
• cmd/
• internal/
• 不能导入来自这些位置的包:

验证正在实施的策略

• Kit 、internal/platform/
• 不允许对任何应用程序问题制定策略
• 不允许记录，但必须解耦对追踪信息的访问
• 配置和运行时更改必须解耦
• 检索指标和遥测值必须解耦
• cmd/、internal/
• 允许对任何应用程序问题设置策略
• 允许以本机方式记录和处理配置

验证接受/返回数据的方式

• All
• 现有类型可能不再适合使用
• 验证给定类型的 值/指针 语义的一致使用
• 当使用接口类型接受值时，重点必须放在所需的方法上，而不是值本身
• 如果不需要方法，则使用具体类型
• 在合理的情况下，在声明新类型之前使用现有类型
• 问题类型来源于暴漏给导出 API 中的依赖项

验证如何处理错误

• All
• 错误已被记录
• 应用程序恢复到了100% 完整性
• 不再报告当前错误
• 处理错误意味着:
• Kit
• 应用程序中不允许panic
• 不允许包装错误
• 只返回根源错误值
• cmd/
• 允许在应用程序中使用panic
• 如果未处理，可以用上下文包装错误
• 大多数处理错误发生在这里
• internal/
• 应用程序中不允许panic
• 如果未处理，可以用上下文包装错误
• 少数处理错误发生在这里
• internal/platform/
• 应用程序中不允许panic
• 不允许包装错误
• 只返回根源错误值

验证测试

• cmd/
• 允许使用第三方测试包
• 可以有一个用于测试的test文件夹
• 与单元测试相比，更要多关注集成测试
• kit/, internal/,internal/platform/
• 在Go中坚持testing包
• 测试文件属于包
• 更多地关注单元测试而不是集成测试

验证recover和panic

• cmd/
• 可以recover任何panic
• 只有当系统可以恢复到100% 完整时
• kit/,internal/,internal/platform/
• goroutine 归一个包所有
• 可以给应用程序提供一个关于panic的事件
• 不能从panic中恢复，除非：

• goroutine 归一个包所有

• 可以给应用程序提供一个关于panic的事件

参考资料