單一職責原則(Single Responsibility Principle) | Clean Architecture 無瑕的程式碼:整潔的軟體設計與架構篇 閱讀筆記

Clean Architecture 無瑕的程式碼:整潔的軟體設計與架構篇

本文為「Clean Architecture 無瑕的程式碼:整潔的軟體設計與架構篇」第 7 章「單一職責原則」的閱讀筆記。

觀念澄清

問題一:不同角色共用方法,導致需求變更時影響到不相關的角色

對於在意精簡程式碼的工程師來說,將重複的邏輯寫成共用的函式是很正常的事。但對於一個模組裡的多個方法,若這些方法分別對不同的角色負責,而方法內共用共同的函式,則若依照任一角色修改共用函式內的邏輯,都會影響到最後回報的目標角色。

例如:模組 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 任一者的規格和需求。

解法就是針對不同角色,分離這些程式碼,也就是分開撰寫成不同的函式,或是根本要拆成不同的模組。

總結

每個模組只對唯一一個角色負責。若發現模組內的函式是面對不同的角色,就把它拆出去!

看更多


Clean Architecture 無瑕的程式碼 Clean Code OOP 物件導向程式設計 閱讀筆記