單一職責原則（Single Responsibility Principle） | Clean Architecture 無瑕的程式碼：整潔的軟體設計與架構篇 閱讀筆記
26 Aug 2020
本文為「Clean Architecture 無瑕的程式碼：整潔的軟體設計與架構篇」第 7 章「單一職責原則」的閱讀筆記。
觀念澄清
- SRP 是指「每個模組只對唯一一個角色負責」。
- SRP 不是指「每個模組只做一件事情」，因為這是重構「函式」的事-應更正為「每個函式只做一件事情」。注意，「每個函式只做一件事情」意味著把職責劃分清楚，降低每個函式的複雜度，只要單純負責實現某個特定目的即可。
問題一：不同角色共用方法，導致需求變更時影響到不相關的角色
對於在意精簡程式碼的工程師來說，將重複的邏輯寫成共用的函式是很正常的事。但對於一個模組裡的多個方法，若這些方法分別對不同的角色負責，而方法內共用共同的函式，則若依照任一角色修改共用函式內的邏輯，都會影響到最後回報的目標角色。
例如：模組 M 包含方法 A、B、C，其中 A、B、C 皆共用方法 D，且 A、B、C 都面對不同的商業邏輯；若 D 必須依照 A 的商業邏輯修改 D，則 D 的產出結果可能無法合乎 B 和 C。
因此，一個模組內應對唯一一個角色負責，就不會因不同角色的需求而必須修改共用函式，而影響不同的角色所得到的結果。也就是說，不同角色所依賴的程式碼，必須要分開。
問題二：不同角色共用方法，修改後的合併是有風險的
不同角色同時想對共用的部份進行修改，因此各自開了分支來做調整，改完後要合併進入主線，此時必然產生衝突，就算現今版本控管工具十分發達，但依舊在合併程式碼時是有風險的。
同上例，模組 M 包含方法 A、B、C，其中 A、B、C 皆共用方法 D，且 A、B、C 都面對不同的商業邏輯；若 D 分別依照 A 和 B 的商業邏輯修改 D，之後再合併程式碼的時候，D 可能會出現很多 bug，最後皆無法滿足 A、B、C 任一者的規格和需求。
解法就是針對不同角色，分離這些程式碼，也就是分開撰寫成不同的函式，或是根本要拆成不同的模組。
總結
每個模組只對唯一一個角色負責。若發現模組內的函式是面對不同的角色，就把它拆出去！
