根据 Go 的哲学，你应该尽量不要对你的解决方案进行过度设计。

Go 最主要的文化就是保持简单、接地气的代码，不产生其他冗余的抽象并将可维护性放置在第一位。同时，人们应该将大多数时间花费在代码上面，而不是纠结在各种工具和环境上面的选择和维护上。

Go 的所有哲学都透露出一个相同的东西：最好只有一种做事的方式。

需要简单说明一点的是，当你需要构建相对比较复杂的抽象时，Go 也是可以支持的。这也是用简单换来的权衡。

如果你真的需要写很多关系复杂的抽象代码，使用像 Java 或者 Python 这样的语言会更适合，然而有这种需求的场景真的很罕见。

所以相关链接中的代码你可能真的仅仅需要看看，而未必会用在项目中。

设计模式的主要原则

先复习一下自己以前写的 面向对象设计实践指南 1。

SOLID 原则

1. 单一职责原则 Single Responsibility Principle
   • 尝试用一句话来描述类。如果这种描述中出现 “或、和、并” 这样的字，那么这个类就具备了多种职责。
2. 开闭原则 Open Close Principle
   • 对扩展开放，对修改关闭。
   • 表象上看是在程序需要进行拓展的时候，不能去修改原有的代码。深层上看要使用接口和抽象类。
3. 里氏代换原则 Liskov Substitution Principle
   • 子类可以替代父类。
4. 接口隔离原则 Interface Segregation Principle
   • 客户端不应该强行依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上。
   • 使用多个隔离的接口，比使用单个接口要好。
   • Go 默认推荐，因为其推荐单一接口，Ruby 中使用职责更内聚的 module。
5. 依赖倒转原则 Interface Segregation Principle
   • 对接口编程，依赖于抽象而不依赖于具体。
   • 比如 A 依赖了 B，转换成 A 依赖 B 的抽象，这样即使 B 换了也无所谓。

KISS 原则

Keep It Simple, Stupid 的首字母缩略字，是一種歸納過的經驗原則。KISS 原则是指在设计当中應當注重簡約的原则。總結工程専業人員在設計過程中的經驗，大多數系統的設計應保持簡潔和單純，而不摻入非必要的複雜性，這樣的系統運作成效會取得最優；因此簡單性應該是設計中的關鍵目標，尽量迴避免不必要的複雜性。

YAGNI 原则

适可而止，You Ain’t Gonna Need It。这是 极限编程 提倡的原则，指的是你自以为有用的功能，实际上都是用不到的。因此，除了最核心的功能，其他功能一概不要部署，这样可以大大加快开发。它背后的指导思想，就是尽可能快、尽可能简单地让软件运行起来。

当你准备列出一个项目清单时，试着考虑以下问题：

• 通过降低抽象的层级，来降低复杂度
• 根据特性将功能独立出来
• 适度接受非功能性需求
• 识别耗时的任务，并摆脱它们

这些原则看似简单，但在实际运作中，会有各种各样的问题出现。一旦你强迫自己应用这些原则，你会发现你距离创造一个完美的软件已经不远了。

其他

1. 迪米特法则
   • 最少知道原则，一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
   • 将某条消息通过第二个不同类型的对象转发给第三个对象。
2. 合成复用原则 Composite Reuse Principle
   • 原则是尽量使用合成/聚合/组合的方式，而不是使用继承。
3. 三次原则 Rule Of Three
   • 因为 DRY 和 YAGNI 实际上有冲突，因此三次原则指的是当某个功能第三次出现时，才进行”抽象化”。

相关链接

1. 设计模式 Golang实现－《研磨设计模式》读书笔记
2. 超赞的GO语言设计模式和成例集锦
3. Go Patterns
4. Some useful patterns

按顺序阅读，2 是 3 的中文目录。