在軟體開發領域，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 部落格 - 單一職責原則