單一職責原則

​

什麼是單一職責原則？

單一職責原則是一種設計規則，主張每個軟體元件應該只有一個主要職責或目的。當一個類別或模組承擔多個職責時，對其中一個職責的修改可能會無意中影響其他職責，從而產生難以維護和測試的脆弱系統。

「一個類別應該只有一個變更的理由。」 — Robert C. Martin

該原則的名稱源於「一次只做一件事」的理念。在實踐中，這意味著將不同的關注點分離到不同的模組中。例如，處理使用者驗證的類別不應該同時格式化資料顯示——這是兩個不同的職責：安全和展示。當顯示格式發生變化時，你不需要修改驗證邏輯，反之亦然。

​

單一職責原則的三個層次

• 入門: 識別程式碼中不同的「變更理由」。如果需求變化會迫使你出於多個目的修改某個類別，那麼該類別可能違反了SRP。
• 實踐: 在函數層面同樣應用SRP。一個函數應該做一件事：把輸入轉換為輸出。如果你在描述一個函數時發現自己要說「而且」，就應該考慮拆分它。
• 進階: 使用「變更軸線」測試。問自己：「如果X領域的需求發生變化，我需要修改這個類別嗎？」如果多個領域都回答「是」，那麼這個類別就承擔了多個職責。

​

起源

單一職責原則由Robert C. Martin（人稱「Uncle Bob」）在其2003年出版的《敏捷軟體開發：原則、模式與實踐》一書中推廣開來。Martin將SRP作為後來被稱為SOLID原則的一部分引入——這是一套物件導向編程的五大設計指南。 這一概念本身早於Martin的正式表述。開發者早就認識到，將不相關的功能組合在一起會造成維護上的噩夢。然而，Martin將這一原則提煉為一條可檢驗的規則：計算一個類別可能需要變更的理由數量。如果超過一個，就違反了SRP。 該原則隨著更廣泛的敏捷運動而獲得關注，敏捷運動強調迭代開發和適應變化需求的能力。在敏捷背景下，易於修改的程式碼是有價值的——SRP透過減少不相關關注點之間的耦合直接實現了這一點。

​

核心要點

​

應用場景

​

經典案例

2003年，一家金融服務公司對其交易平台進行了重大改造。原始程式碼庫有一個名為「Trade」的類別，處理驗證、持久化、通知、報表和風險計算。由於緊耦合，任何一個方面的變更——比如新增的通知渠道——都需要對整個系統進行測試。 團隊使用SRP進行了重構，將Trade類別拆分為五個專注的類別：TradeValidator、TradeRepository、TradeNotifier、TradeReporter和RiskCalculator。每個類別只有一個職責，可以獨立修改。 結果非常顯著。由於回歸測試要求而產生的原本需要數天才能修復的缺陷，現在可以在幾小時內解決。新增的通知渠道只需要修改TradeNotifier類別即可。在接下來的一年中，團隊報告新功能的部署時間減少了40%。 這個案例說明了SRP的實踐價值：雖然分離職責的前期成本需要思考，但長期在可維護性和開發速度方面獲得的收益是 substantial 的。

​

邊界與失效場景

SRP最常見的誤用是過度拆分。建立「每個方法一個類別」反而適得其反，因為會產生一個難以導航的系統。該原則的核心是關於內聚性——將相關事物分組——而不是任意最小化類別的大小。 另一個失敗模式是錯誤識別職責。「變更理由」有時是主觀的。一個同時處理信用卡和銀行轉帳的PaymentProcessor可能看起來像是兩個職責，但如果兩者的業務邏輯緊密交織，拆分它們可能會增加複雜性。 邊界條件：當由於耦合導致的變更成本超過管理更多元件的成本時，才應用SRP。從內聚的設計開始，當注意到一個類別因多個不相關的原因需要變更時，再向SRP方向重構。

​

常見誤區

​

相關概念

單一職責原則是一個設計原則家族的成員，這些原則共同促進軟體的可維護性：

​

一句話總結