概念位置

SRP 是 SOLID 五原則的第一條。Martin 在《Agile Software Development: Principles, Patterns, and Practices》（2002）把它寫成「一個類別應該只有一個改變的理由」；2014 年他在〈The Single Responsibility Principle〉一文說明「理由」指的是人，並把原則改寫成兩句方向相反的指示：

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

前一句要求把因同一個理由改變的程式碼放在一起，後一句要求把因不同理由改變的程式碼分開。切分的人只執行後一句，會把同一個理由的程式碼拆散到很多檔案，於是那群人每次提出變更，修改的人都要同時改好幾處，這就是 Shotgun Surgery；只執行前一句的極端是把所有程式碼都放在一起，於是不同理由的變更擠在同一個模組，這就是 Divergent Change。SRP 要求兩句同時滿足：因同一個理由改變的程式碼在同一個模組，因不同理由改變的程式碼在不同模組。在《Clean Architecture》（2017）裡，Martin 把定義收斂成「A module should be responsible to one, and only one, actor」，actor 指的是要求同一類變更的一群人。

理由的計數單位是改動的種類，提出的人用來辨認種類。 一個 actor 要求的是同一類改動，所以理由可以從兩邊辨認：從提出變更的人，或從他們要求的改動種類。兩邊對得上時（財務部門要求的都是薪資規則的改動）看哪一邊結果都一樣；對不上時以改動種類為準——同一個人轉達好幾個職能的需求時，他提出的改動屬於不同理由；不同的人提出同一類改動時，仍是同一個理由。

Martin 在 2014 年那篇文章裡說明這條原則的源頭是 David Parnas 1972 年的論文〈On the Criteria To Be Used in Decomposing Systems into Modules〉與 Edsger Dijkstra 提出的 separation of concerns：模組的切法要依「什麼會一起變」決定，不依程式執行的步驟決定。他在《Agile Software Development》的單一職責那一章也寫明，這條原則就是 Tom DeMarco 與 Meilir Page-Jones 所說的 Cohesion（內聚），只是把判斷依據從功能上的相關換成讓模組改變的力量。

「只做一件事」是另一條原則。 SRP 最常見的誤讀是「一個類別只做一件事」。Martin 在《Clean Architecture》第七章說確實有一條原則是這樣講的，那條原則的對象是函式：一個函式只做一件事，用在把大函式拆小的重構裡。那一條管的是函式內部的步驟，判斷依據是程式碼在做什麼；SRP 管的是模組的邊界，判斷依據是誰會要求它改變。兩條原則的單位與依據都不同，所以一個只做一件事的類別仍然可能有兩個改變的理由，一個做了好幾件事的類別也可能只有一個。

可觀察訊號與例子

Martin 的例子是一個 Employee 類別，裡面有三個方法：calculatePay 依財務部門的規則計算薪資，reportHours 依營運部門的需要產生工時報表，save 依技術團隊選定的方式寫進資料庫。三個方法服務三群人——財務長、營運長、技術長各自管轄的部門——所以這個類別有三個改變的理由。三個方法放在同一個類別，損害出現在它們共用程式碼的時候：Martin 在《Clean Architecture》裡舉的是 calculatePay 與 reportHours 共用一個計算正常工時的 regularHours 方法：財務部門要求調整加班時數的算法，負責這次修改的工程師改了那段共用計算，營運部門的工時報表跟著變，而營運部門沒有提出任何變更。

判斷一個模組有幾個理由，要看它的變更要求的是哪幾種改動、各由哪一個職能決定，不看它有幾個方法：

• 修改紀錄裡有好幾個不相干的需求改同一個檔案（不相干指要求的改動屬於不同種類）：這是改變理由不只一個的間接量測。不同理由的修改由不同的人同時進行時，改動落在同一處就會合併衝突，沒有文字衝突時也要重跑測試確認沒有改壞對方；Martin 把合併列為違反單一職責的另一個症狀。用 git 歷史統計每個檔案被幾個不同的需求修改，再逐個 commit 歸類，做法在從修改紀錄畫模組邊界，造成等待的幾種情形在那一篇的〈修改競爭與單一職責原則〉。
• 一個需求的修改改壞了另一個需求在乎的行為：上面 Employee 的情形。兩個需求互不相干，卻因為住在同一個模組而互相影響。
• bug 修正與重構不另算一個理由。Martin 的說法是 bug 修正與重構是程式設計師的責任，不是程式的；歸類時，一個 bug 修正併進它所修的那段程式碼原本屬於的那一類。
• 所有需求都由同一個人提出時（例如所有票都由同一位 PM 開），看提出的人分不出理由，要看每個需求要求的是哪一種改動。以一個擋下跨工作目錄 commit 的守衛腳本為例：解析 git 命令語法的改動跟著 git 的寫法變，判斷其他代理人是否正在工作的改動跟著團隊的並行流程變，擋下時印給使用者的訊息措辭跟著使用者回饋變，這三種改動各是一個理由。

依改動種類計數理由的判斷也適用於文件：一份文件被好幾個不相干的主題修改，就有好幾個改變它的理由，做法在依職責拆分文字文件。

設計責任

套用 SRP 的設計責任是讓每一群提出變更的人，各自只需要改一個地方，而且改的時候不會動到別人在乎的行為。執行的判斷問句是：列出一段時間內改過這個模組的需求（範圍要涵蓋幾輪需求，選法見從修改紀錄畫模組邊界〈用 git 歷史量出熱點〉的「統計的時間範圍」一條），逐一寫出要求的是哪一種改動、由哪一個職能決定；改動種類有兩種以上，就有兩個以上的理由，可以考慮依理由切開。

依技術層次切（驗證器、資料存取、寄信服務各一個類別）常常與依理由切重合，因為驗證規則、資料庫結構與信件內容通常由不同的人決定；兩種切法分岔時，以每個類別會被哪一個職能要求改變為準。切開之後反過來檢查：同一個理由的變更是否需要同時改好幾個新模組，是的話就切過頭了，要把那幾個新模組併回來。

SRP 與 開放封閉原則常一起使用：SRP 決定模組的邊界畫在哪裡，開放封閉原則決定模組裡哪些部分對外公開、讓其他模組不必修改它就能擴充，哪些留在內部。開放封閉原則在 Python 的寫法與例子在開放封閉原則。

概念位置

Divergent Change 與 Shotgun Surgery 描述的是同一組對應關係的兩種失衡：改變的理由與模組之間應該一對一。同一個理由的好幾個需求都改同一個模組是正常的內聚；屬於不同理由的需求改同一個模組是 Divergent Change，同一個理由的一個需求要改好幾個模組是 Shotgun Surgery。單一職責原則的兩句指示各自對應一種：「把因不同理由改變的程式碼分開」修的是 Divergent Change，「把因同一個理由改變的程式碼放在一起」修的是 Shotgun Surgery。

可觀察訊號與例子

Fowler 給的辨識方式是：修改某個模組時，心裡想的是「加一種資料庫要改這三個函式，加一種金融商品要改那四個函式」——兩種變更各自集中在模組裡的幾個函式，卻共用同一個模組。可以觀察到的訊號有三種：

• 修改紀錄：同一個檔案在一段時間內被好幾個不相干的需求修改。以需求編號統計每個檔案被幾個不同需求改過，再逐個 commit 歸類，做法在從修改紀錄畫模組邊界。
• 並行開發的等待：處理不相干需求的人反覆在同一個檔案上解合併衝突、或等對方合併之後重跑測試。
• 檔案內的分群：模組裡的函式可以分成幾群，每一群只被某一類需求修改，群與群之間很少一起改。

站內偵測規則（以方法分組數判斷）與 Extract Class 的操作範例在 Code Smell 檢查清單。

設計責任

修正 Divergent Change 的方向是依改變的理由把模組切開：先找出每一類需求各自會改的那一群函式與資料，再用 Extract Class（拆出類別）或把模組改成套件、每一群移到一個子模組。切開之前先用測試鎖住現有行為，切開之後確認同一類需求的變更只需要改一個新模組；若同一類需求要同時改好幾個新模組，代表切過頭，產生了 Shotgun Surgery。

概念位置

單一職責原則有兩句方向相反的指示：把因不同理由改變的程式碼分開，把因同一個理由改變的程式碼放在一起。只照前一句切，最常出現的結果就是 Shotgun Surgery——切的人看到「做了好幾件事」就切開，沒有檢查那幾件事是不是總是一起改。它與 Divergent Change 都是改變的理由與模組沒有一對一對應的情形，修正方向相反，所以拆檔之後要兩個方向都檢查。

可觀察訊號與例子

Fowler 指出這種壞味道的主要風險是漏改：變更散在很多地方時，很難全部找到，漏掉一處就留下不一致。常見的形態有三種：

• 依行數拆檔：把一個 900 行、只屬於同一個需求連續演進的解析器切成三份，切的時候不看修改落在哪裡，之後同一個主題的修改常常要同時改好幾個檔。行數判斷與不同需求數的判斷在這種檔案上給出相反的結論，對照在從修改紀錄畫模組邊界的〈行數與不同需求數的量測對象〉。
• 新增一個欄位要改每一層：欄位定義、資料存取、序列化、畫面各在一個檔案，加一個欄位就要依序改過每一層。這種情形有時是分層架構刻意付的成本，判斷時看這幾層是不是總是一起改、而且由同一個理由驅動。
• 同一段規則複製在好幾處：規則改了，每一份複本都要找出來改。這與 DRY 處理的是同一件事，Python 的寫法在DRY 原則。

站內偵測規則與修正範例（Extract Interface、Introduce Facade）在 Code Smell 檢查清單。

設計責任

修正 Shotgun Surgery 的方向是提高內聚，把總是一起改的函式與資料收回同一個模組：用 Move Function、Move Field 把散落的函式與資料移到一處，散開的那幾個模組若只剩空殼就用 Inline Class 併回去。判斷問句是：最近幾次同一類變更，各改了哪幾個檔案；每次都改同一組檔案，那一組就是應該合併的候選。合併之後回頭檢查另一個方向：新的模組是否因此開始被不相干的需求修改，是的話就併過頭了，變成 Divergent Change。

概念位置

對擴充開放與對修改封閉看起來互相矛盾：要讓模組有新的行為，通常就得改它。Robert C. Martin 在 1996 年的〈The Open-Closed Principle〉裡給的解法是「抽象是關鍵」：使用端只依賴一個固定的抽象（例如一個介面或抽象類別），新的行為由新的實作提供。使用端依賴的抽象不變，所以使用端不必修改；實作可以一直增加，所以行為可以擴充。用單一職責原則的語言說，單一職責原則畫出模組的邊界，抽象是這條邊界上對外公開的部分，各個實作留在邊界內，其他模組不需要知道。

同一篇文章另有一段〈Strategic Closure〉，是這條原則的使用條件：沒有一個有規模的程式能百分之百封閉，不論模組多「封閉」，總有某一類變更是它擋不住的。Martin 的例子是一個依序畫出所有圖形的函式，它對「新增一種圖形」封閉，對「先畫完所有圓形再畫方形」這種順序規則的變更就不封閉。所以封閉要有選擇：設計者要挑出要封閉的那幾類變更，Martin 給的依據是對使用者與產業的了解，判斷哪幾類變更最可能發生。

「封閉要有選擇」這個條件讓開放封閉原則與 Divergent Change（發散式變更） 接在一起：修改紀錄是「哪幾類變更最可能發生」最直接的證據。一類變更在紀錄裡已經反覆發生、每次都要改同一個模組，就是 Divergent Change 的形態，也是值得封閉的候選。替紀錄裡從沒出現過的那一類變更預先做擴充點，現在就要多寫並維護一層抽象，換到的是一個未必發生的變更變便宜；這是 YAGNI 處理的那種取捨，它在什麼條件下成立見 YAGNI 的真實適用條件。

可觀察訊號與例子

需要開放封閉原則的訊號，是同一類變更反覆要求修改同一段程式碼：

• 依類型分支的函式：一個 if 或 switch 依格式（PDF、Excel、HTML）或類型分派，每新增一種格式就要在這段程式碼裡多加一個分支，並重新確認沒有改壞其他分支。改成每種格式各一個實作、使用端只依賴共同的抽象之後，新增格式變成新增一個實作。
• 集中登記檔：新增一種實作之後，還要回到一份集中的清單登記它。這份清單仍然對「新增實作」不封閉，並行的需求也會在它的尾端同時追加而衝突（處置見從修改紀錄畫模組邊界〈熱點的分類與處理方式〉）；用自動登記（依命名規則或目錄掃描）可以讓這份清單也不必再改，代價是登記關係不再寫在一個看得到的地方。
• 共用的全域狀態：Martin 在同一篇文章裡指出，依賴全域變數的模組，對任何可能改寫那個變數的模組都無法封閉；依賴那個全域變數的模組很少、或那個全域變數不可能被不一致地使用時，損害才小。

各語言的寫法不同：Python 用抽象基類或 Protocol，Go 用 interface，Dart 用 abstract class。Python 的例子在開放封閉原則與認知負擔。

設計責任

套用開放封閉原則的設計責任是選對要封閉的變更。判斷問句是：這個擴充點要擋的那一類變更，在過去的修改紀錄裡發生過幾次，三種結果各有處置：

• 已經反覆發生（紀錄裡有兩次以上、每次都改同一處）：做擴充點。
• 只發生過一次：看對使用者與產業的了解判斷它會不會再發生——例如報表格式由客戶要求、而客戶還會再要新格式——判斷會再發生才做；判斷不出來就先照原樣改，等它第二次發生。
• 從沒發生過：先不做。

擴充點做出來之後，抽象本身成了很多實作共同依賴的對象，修改抽象的成本隨實作數增加，所以抽象只放那一類變更裡每個實作都需要的操作，不放眼前某一個實作才有的細節。

概念位置

DRY 管的對象是知識，不是程式碼的字面。2019 年的第二版特別說明，很多讀者把 DRY 讀成「不要複製貼上程式碼」，而 Hunt 與 Thomas 指的是知識與意圖的重複：同一件事寫在兩個地方，即使兩處的寫法完全不同（一段程式碼與描述它的文件、一份資料庫綱要與對應的資料結構），也是重複。

反方向也成立：兩段字面相同的程式碼，如果因為不同的理由改變，就不是同一份知識。Single Responsibility Principle（單一職責原則）的判斷在這裡接手：兩段程式碼要求的改動屬於不同種類（一段跟著某個職能的規則變、另一段跟著另一個職能的規則變），現在相同只是碰巧，合併成一個共用函式之後，為其中一個需求做的修改會改到另一個需求依賴的行為，那個共用函式就成了 Divergent Change（發散式變更）。Martin 在《Clean Architecture》的單一職責那一章把這種字面相同、理由不同的情形稱為 accidental duplication（意外的重複）。

可觀察訊號與例子

需要套用 DRY 的訊號，是同一份知識的變更要同時改好幾處：

• 同一條規則複製在好幾個檔案：例如四個腳本各自寫了一份相同的 git 指令包裝函式，要改一個 git 指令選項就得改四次。四份都因同一個理由改變（呼叫 git 的方式），是同一份知識，所以抽成一個共用函式、四處改成呼叫它。Python 專案的做法與遷移順序在 DRY 原則與共用程式庫。
• 同一個常數寫在好幾處：例如逾時秒數同時寫在程式碼、設定檔與文件裡。保留一個權威來源（通常是程式執行時實際讀取的那一處，例如設定檔），程式碼讀它、文件連到它。
• 程式碼與文件描述同一件事：文件抄了一份參數清單，程式碼改了而文件沒改。讓文件從程式碼產生，或文件只寫程式碼表達不了的部分。

判斷兩段相似的程式碼要不要合併時，Martin Fowler 在《Refactoring》引述 Don Roberts 的 Rule of Three：第一次照寫，第二次寫出相似的程式碼時先容忍重複，第三次才抽出共用的部分。Rule of Three 決定的是什麼時候判斷，要不要合併仍由下一節的判斷問句決定：等到有三份相似的程式碼，才累積得出足夠的修改紀錄，看得出它們是不是一起改。

設計責任

套用 DRY 的設計責任是讓每一份知識只有一個權威來源，而合併之前先確認那幾段程式碼是同一份知識。判斷問句是：這幾處過去的修改，是否每次都一起改、而且由同一個需求驅動；兩個條件都成立才是同一份知識，合併；任一個不成立，字面相同也分開保留。合併之後，函式裡開始需要一個參數來分支成兩套行為，代表那兩套行為各自由不同的理由改變，是合併錯了的訊號。

概念位置

內聚依「這些元素為什麼放在一起」分成幾種。由弱到強的排序依據是放在一起的理由與模組那件工作的關係有多緊：偶然內聚的元素之間完全無關，功能內聚的每個元素都屬於同一件工作。

• 偶然內聚（coincidental）：放在一起沒有任何理由，例如一個什麼都放的 utils 模組。
• 邏輯內聚（logical）：元素屬於同一個類別，例如所有輸入處理都放在一起，而每一種輸入的處理彼此無關。
• 時間內聚（temporal）：元素在同一個時間點執行，例如程式啟動時要做的所有初始化。
• 程序內聚（procedural）：元素總是依某個順序執行。
• 通訊內聚（communicational）：元素操作同一份資料。
• 循序內聚（sequential）：一個元素的輸出是下一個元素的輸入。
• 功能內聚（functional）：所有元素一起完成一件定義明確的工作。

Robert C. Martin 在《Agile Software Development》的單一職責那一章寫明，這條原則在 Tom DeMarco 與 Meilir Page-Jones 的著作裡已有描述，「They called it cohesion」，他們把內聚定義成模組元素在功能上的相關程度；Martin 在那一章把內聚的意思稍微移動，改成和「讓模組改變的力量」相關。兩種判斷用到的資訊不同：功能相關看程式碼在做什麼，單一職責原則看誰會要求它改變。兩種判斷可能給出不同結果：一個模組完成一件定義明確的工作，屬於功能內聚；如果那件工作的規則由兩個業務職能各管一半，它仍然有兩個改變的理由。決定要不要拆時以改變的理由為準，內聚的層級用來描述元素放在一起的理由屬於哪一種。

可觀察訊號與例子

低內聚的模組有幾個可以觀察到的訊號：

• 名字說不出它做什麼：utils、helpers、common、misc 這類名字通常代表偶然內聚，裡面的函式彼此沒有關係，只是沒有更好的去處。
• 改一處要讀整個模組，而讀到的大部分與這次修改無關：模組裡混了幾群互不相關的元素。
• 修改紀錄裡同一個模組被不相干的需求輪流修改：這是內聚不足在版本歷史上的樣子，也就是 Divergent Change（發散式變更）。

反方向的錯誤是把同一件工作拆到好幾個模組，每個模組單獨看都很小，而那件工作的每一次修改都要同時改它們，這是 Shotgun Surgery（散彈式修改）。

設計責任

提高內聚的設計責任是讓模組裡的每個元素都因為同一個理由放在這裡，理由指的是改變的理由：它會因為哪一種改動而改變。判斷問句是：逐一寫出模組裡每個元素會被哪一種改動要求修改（那一類改動由哪一個職能決定）；同一種改動的那一群留下，屬於別種改動的、或寫得出的原因只有「沒有別的地方放」的，移到它所屬的模組。移完之後回頭看 Coupling（耦合）：移出去的元素如果仍然大量讀寫原模組的內部資料、而且每次修改都要和原模組一起改，那個元素與原模組本來就屬於同一個模組，移出去的判斷錯了。

概念位置

耦合依兩個模組共享的內容分成幾種，由強到弱是：

• 內容耦合（content）：一個模組直接使用另一個模組內部的程式碼或資料，例如跳進對方的內部、改對方的私有欄位。
• 共用耦合（common）：好幾個模組存取同一份全域資料。
• 外部耦合（external）：模組共用一個外部規定的資料格式、通訊協定或裝置介面。
• 控制耦合（control）：一個模組傳一個旗標給另一個模組，由旗標決定接收的模組要走哪一條邏輯。
• 戳記耦合（stamp，其他中文資料也寫作「標記耦合」）：模組之間傳遞一整個複合資料結構，而接收的一方只用到其中一部分欄位。
• 資料耦合（data）：模組之間只透過參數傳遞需要的資料。

耦合越強，一個模組的修改越可能要求另一個模組跟著改。Open-Closed Principle（開放封閉原則）用來降低耦合的手段是讓使用端只依賴一個固定的抽象：使用端與各個實作之間只剩下對那個抽象的依賴，實作的內部改變不會傳到使用端。

可觀察訊號與例子

耦合過強的訊號，是修改一個模組時發現要同時改另一個模組，而這次修改的需求只跟被修改的那個模組有關：

• 改一個模組的內部欄位，另一個模組編譯失敗或行為改變：另一個模組直接讀寫了這些欄位，是內容耦合。
• 改一份全域設定，幾個看似無關的模組行為都變了：它們共用同一份全域資料，是共用耦合。Martin 對全域變數的說明在 Open-Closed Principle 卡片。
• 函式收一個 mode 或 is_xxx 參數，依它切換成完全不同的兩套行為：呼叫端在控制被呼叫端的流程，是控制耦合；這種函式通常也代表兩套行為各自有不同的改變理由，拆成兩個函式之後，呼叫端直接呼叫它要的那一個。
• 函式收一整個物件、只讀其中一兩個欄位：例如計算運費的函式收整個訂單物件，只讀了寄送地址。訂單物件的結構一改，運費函式就要重新確認，是戳記耦合；測試這個函式時也得先造出一整個訂單物件。改成只收寄送地址，就降成資料耦合。

兩個模組之間有耦合本身不是錯誤，模組要合作就一定要交換資料或呼叫對方。要確認的是交換的內容是否只有完成這次呼叫實際用到的資料。

設計責任

降低耦合的設計責任是讓模組之間只交換合作需要的資料，而且依賴的方向穩定。判斷問句是：改這個模組時，有哪些別的模組要跟著改，原因是什麼；原因是那些模組讀了這個模組的內部、共用了同一份可變資料、或用旗標控制這個模組的流程，就把那份依賴改成更弱的形式，依情形選一種：只傳它實際用到的資料（降成資料耦合），或改成依賴一個抽象（做法見開放封閉原則）。降低耦合之前先確認那兩個模組是否本來就該是同一個：兩者過去的修改幾乎每次都一起發生，或一方大量讀寫另一方的內部資料，拆成兩個模組只會讓每次修改都要改兩處，形成 Shotgun Surgery（散彈式修改）。這時把兩者合併成一個模組比降低它們之間的耦合更合適，合併之後它們放在一起的理由相同，內聚也隨之提高。