Princípios SOLID em GoLang - 單一職責原則 (SRP)

在軟體開發的世界中，SOLID 原則告訴我們如何組織函數和數據，以便我們的程式碼：

• 容忍變化
• 簡單易懂
• 成為可在許多軟體系統中使用的組件的基礎

術語「SOLID」是五個設計假設的縮寫，如下所述：

(S) 單一職責原則：「一個模組必須有一個且只有一個改變的理由」
（）開放/封閉原則：「軟體工件必須對擴充開放，但對修改關閉」
(L) 里氏替換原則：「衍生類別必須可以被其基底類別取代」
(I) 介面隔離原則：「不應強迫類別實作它不會使用的介面與方法」
(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 部落格 - 單一職責原則

以上是Princípios SOLID em GoLang - 單一職責原則 (SRP)的詳細內容。更多資訊請關注PHP中文網其他相關文章！