在软件开发领域，SOLID原则告诉我们如何组织函数和数据，以便我们的代码：

• 容忍变化
• 简单易懂
• 成为可在许多软件系统中使用的组件的基础

术语 SOLID 是五个设计假设的缩写，如下所述：

(S) 单一职责原则：“一个模块必须有且只有一个改变的理由”
(O) 开放/封闭原则：“软件工件必须对扩展开放，但对修改关闭”
(L)里氏替换原则：“派生类必须可以被其基类替换”
(一)接口隔离原则：“不应该强迫一个类实现它不会使用的接口和方法”
(D) 依赖倒置原则：“依赖于抽象而不是实现”

SOLID 和 Go 语言

SOLID 是为面向对象编程而设计的，众所周知，GoLang 并不是采用这种范式的语言。但是，我们可以使用它提供的资源来满足 OOP 方法。例如，Go 没有继承支持，但这个想法可以通过其组合支持来补偿。类似地，可以使用接口创建一种多态性。

在这篇文章（共 5 篇文章中的第一篇）中，我打算通过与我们日常遇到的情况接近的示例来详细说明第一个原则。

单一职责原则（SRP）

我们已经知道该术语的含义，现在是时候学习如何在 GoLang 中实现它了。
在这种语言中，我们可以将这一原则定义为“一个函数或类型必须有一项且仅有一项工作，以及一项且仅有一项责任”，让我们看下面的代码：

上面，我们有一个名为 userService 的结构。它有两个属性：db，负责与关系数据库通信；amqpChannel，支持与 RabbitMQ 消息服务通信。

UserService 实现了一个名为 Create 的方法。在此方法中，我们将接收到的用户信息存储在数据库中，然后将数据发布到 RabbitMQ。
可见userService中Create方法的职责不只是一个，而是两个：在数据库中存储信息和在RabbitMQ队列中发布消息。

这可能会导致几个问题，例如：

• 难以维护：如果其中一项需求发生变化，例如用户数据的序列化方式，您将不得不修改Create方法的逻辑，即使这与您的主要职责无关，即将数据保存到数据库中。
• 测试难度：由于 Create 方法有两个不同的职责，因此您必须为每个方法创建测试，这可能很困难且费力。
• 不必要的耦合：将用户数据发布到 RabbitMQ 队列的逻辑完全独立于将该数据保存到数据库的逻辑。在同一个方法中混合这两种职责会产生不必要的耦合。

在下面的代码中，我们修改结构以尊重 SRP。一探究竟：

请注意，我们已将职责分为三个不同的部分：存储库 UserRepository 将用户保存到数据库，发布者 UserPublisher 将消息发送到 RabbitMQ，以及服务 UserService 协调这两个操作。

这样，每个组件负责特定的、独立的任务，方便代码的维护和演进，此外还允许这些部分中的每一个被替换或改进而不影响其他部分。例如，如果需要更改所使用的数据库，只需更换存储库即可。如果需要改变传播形式，只需更换发布者即可。

值得一提的是，执行两个不同的任务和委派其执行之间存在细微的区别。在userService.Create的原始示例中，在一个地方执行了两个操作，违反了单一责任原则。重构后，我们将执行委托给不同的结构体，Create 方法只负责协调这个流程。

为了在此示例中应用 SRP，我们最终还实施了其他一些 SOLID 原则：

• 接口隔离原则 (ISP)：每个接口代表一个职责。 UserRepository 和 UserPublisher 都是只有一种方法的接口，每个方法代表一个职责。
• 依赖倒置原则（DIP）：userService结构依赖于抽象（接口）而不依赖于具体实现，也就是说，它不知道UserRepository和UserPublisher的具体实现，只知道他们实现的接口。
• 开放/封闭原则（OCP）：代码对于扩展是开放的，因为可以轻松添加新的存储库或发布者，而无需修改 userService。

在本系列的下一篇文章中，我将通过具体示例对它们进行更详细的解释。

再见，伙计们！

参考：
SOLID：面向对象设计的前 5 个原则
Clean Coder 博客 - 单一职责原则