單一職責(zé)原則（Single Responsibility Principle，SRP）是 SOLID 五大原則中的第一條，由 Robert C. Martin（“Uncle Bob”）提出。它是軟件設(shè)計中最基礎(chǔ)、也最容易被誤用的原則。和它的名字不同，它并不是“一個類只做一件事”那么簡單，而是：

一個類應(yīng)該只有一個引起其變化的原因。

A class should have only one reason to change.

SRP 專注于“變化來源”。它要求開發(fā)者將軟件中不同變化的方向分離，使每個類（或模塊）對一種變化負(fù)責(zé)。

如果一個類承擔(dān)了多種不同類型的職責(zé)，那么任何一種職責(zé)發(fā)生變化時，都可能迫使類被修改，最終導(dǎo)致代碼變得脆弱、龐大、難以維護(hù)。

一、為什么需要單一職責(zé)原則？

軟件之所以會難維護(hù)，很大程度上是因為“多個變化糾纏在一起”。SRP 通過“解耦變化來源”來提高可維護(hù)性。

（1）多個職責(zé)會讓類變得不穩(wěn)定

例如，當(dāng)日志、業(yè)務(wù)邏輯、數(shù)據(jù)存儲、驗證規(guī)則混在一個類里時，其中任何一個需求變更都會讓整個類被修改。

（2）修改一個功能容易破壞另一個功能

當(dāng)職責(zé)混合時，影響范圍無法隔離。一個修改可能引發(fā)連鎖錯誤。

（3）類越“胖”，越難測試

不同職責(zé)對應(yīng)的依賴越來越多，編寫單元測試也越來越麻煩。

（4）不利于復(fù)用

你可能想復(fù)用其中一部分能力，卻不得不引入整個龐大的類。

SRP 的目標(biāo)是：讓變化各自為政，而不是綁在一起互相拖累。

二、SRP 的定義與本質(zhì)

Uncle Bob 的經(jīng)典定義是：如果一個類有多個變化原因，那么它就承擔(dān)了多個職責(zé)。其關(guān)鍵不在于功能的數(shù)量，而在于變化來源的不同。

例如，下面這個“訂單處理器”類承擔(dān)了三個彼此獨(dú)立的變化來源：

    def notify(self, order): ...    # 通知方式（因系統(tǒng)升級而變）

這三類變化互不相關(guān)，擠在同一個類里便違反了 SRP。

SRP 的本質(zhì)是：

? 職責(zé)決定變化

? 變化決定邊界

? 邊界決定代碼結(jié)構(gòu)

一個“職責(zé)”就是一種“未來可能變化的方向”。

現(xiàn)實類比：為什么 SRP 如此重要？

想象學(xué)校里一位老師同時負(fù)責(zé)：教語文、數(shù)學(xué)、歷史、體育、心理輔導(dǎo)、班級行政管理。如果學(xué)校對“體育課”進(jìn)行課程改革：

? 這位老師需要調(diào)整體育課教學(xué)方案

? 但語文課、數(shù)學(xué)課、行政任務(wù)等都可能被連帶影響（時間沖突、工作壓力增大等）

? 其他課程也可能被迫改變排課方式

這種變化互相干擾，就是 SRP 試圖避免的局面。

如果每個老師只負(fù)責(zé)一門學(xué)科，那么課程改革僅影響對應(yīng)老師，不會牽連全校。

SRP 做的就是：把變化來源分開，讓一個需求變化只影響一塊代碼，而不是“牽一發(fā)而動全身”。

三、Python 中常見的 SRP 違例場景

Python 靈活的語法常導(dǎo)致類很快變得臃腫。

以下是一些典型反例：

（1）“全能處理器 / God Class”

例如一個視圖類同時處理：數(shù)據(jù)校驗、ORM 查詢、業(yè)務(wù)邏輯、異常處理、序列化、日志、通知推送。一旦任何一部分發(fā)生變化，都必須修改同一個類。

（2）模型類承擔(dān)業(yè)務(wù)行為

例如 Django model 中塞入校驗規(guī)則、折扣計算、推送通知、導(dǎo)出報表，導(dǎo)致模型類因不同變化頻繁變動。

（3）工具類變成“垃圾桶”

當(dāng) utils.py 中含有幾十種不相關(guān)的方法時，它本質(zhì)上已經(jīng)不是“一個職責(zé)”，而是“多個變化來源的集合”。

（4）控制器負(fù)責(zé)“所有事情”

例如：

    ...

一次需求改動可能讓整個函數(shù)全部變動。

四、如何遵守 SRP：拆分的正確方式

（1）按變化來源拆分類（最核心方法）

從“訂單處理器”示例重新設(shè)計：

        self.notifier.notify(order)

職責(zé)明確、變化隔離。

（2）使用抽象類（ABC）或協(xié)議（Protocol）隔離職責(zé)

為職責(zé)定義接口，讓不同實現(xiàn)各自獨(dú)立變化。

    ...

（3）函數(shù)級別也適用 SRP

如果一個函數(shù)負(fù)責(zé)校驗、計算、轉(zhuǎn)換格式，那么它承擔(dān)了三個變化來源。建議拆分為：

def format_response(order): ...

（4）適度拆分，不要過度設(shè)計

如果兩個功能總是一起變化，那么它們屬于同一職責(zé)，不用拆。

例如 Point 與 distance 計算、User 對象與其基本字段轉(zhuǎn)換，通常不必分開。

SRP 的目的是降低變化的影響，而不是追求碎片化設(shè)計。

五、實例：用 SRP 優(yōu)化一個現(xiàn)實場景

不符合 SRP：一個類承擔(dān)所有職責(zé)

    def send_email(self, pdf): ...

四種變化來源：數(shù)據(jù)來源變、分析規(guī)則變、渲染方式變、通知渠道變。任何一處變化都會影響整個類。

符合 SRP：職責(zé)清晰的設(shè)計

        self.sender.send(pdf)

每個類都只有一個變化原因，類結(jié)構(gòu)更加可靠。

小結(jié)

單一職責(zé)原則要求一個類應(yīng)當(dāng)僅有一個引起變化的原因。它并不限制一個類做多少事，而是強(qiáng)調(diào)“一個類的所有行為必須屬于同一種變化來源”。遵循 SRP 可帶來更穩(wěn)定的設(shè)計、更低的維護(hù)成本、更高的可擴(kuò)展性以及更易理解與測試的代碼結(jié)構(gòu)。在 Python 這類動態(tài)語言中，由于缺乏編譯期檢查，更需開發(fā)者主動運(yùn)用 SRP 來構(gòu)建健壯的代碼模型。作為 SOLID 原則的基石，SRP 幫助代碼在變化中保持穩(wěn)定，而非陷入混亂。

“點(diǎn)贊有美意，贊賞是鼓勵”