1 簡介
-
定義
不要存在多于一個導緻類變更的原因。
-
特點
一個類/接口/方法隻負責一項職責。
-
優點
降低類的複雜度、提高類的可讀性，提高系統的可維護性、降低變更引起的風險。
- 名字容易讓人望文生義，大部分人可能了解成：一個類隻幹一件事，看起來似乎很合理呀。幾乎所有程式員都知道“高内聚、低耦合”，應該把相關代碼放一起。
若随便拿個子產品去問作者，這個子產品是不是隻做了一件事，他們異口同聲：對，隻做了一件事。看來，這個原則很通用啊，所有人都懂，為啥還要有這樣一個設計原則？
因為一開始的了解就是錯的！錯在把單一職責了解成有關如何組合的原則，實際上，它是關于如何分解的。
Robert Martin對單一職責的定義的變化：
《靈活軟體開發：原則、實踐與模式》
一個子產品應該有且僅有一個變化的原因
《架構整潔之道》
一個子產品應該對一類且僅對一類行為者（actor）負責
單一職責原則 V.S 一個類隻幹一件事
最大的差别就是，将變化納入考量。
分析第一個定義：一個子產品應該有且僅有一個變化的原因。
軟體設計關注長期變化，擁抱變化，我們最不願意面對卻不得不面對，隻因變化會産生不确定性，可能：
新業務的穩定問題
舊業務遭到損害而帶來的問題
是以，一個子產品最理想的狀态是不改變，其次是少改變，它可成為一個子產品設計好壞的衡量标準。
但實際開發中，一個子產品頻繁變化，在于能誘導它改變的原因太多！
2 案例
2.1 鳥類案例
- 最開始的 Bird 類
-
單一職責原則（Single Responsibility Principle，SRP）（上）1 簡介2 案例 - 簡單測試類
-
單一職責原則（Single Responsibility Principle，SRP）（上）1 簡介2 案例 - 顯然鴕鳥還用翅膀飛是錯誤的！于是，我們修改類實作
-
單一職責原則（Single Responsibility Principle，SRP）（上）1 簡介2 案例 - 這種設計依舊很low，總不能一味堆砌 if/else 添加鳥類。結合該業務邏輯，考慮分别實作類職責，即根據單一原則建立兩種鳥類即可：
-
單一職責原則（Single Responsibility Principle，SRP）（上）1 簡介2 案例 -
單一職責原則（Single Responsibility Principle，SRP）（上）1 簡介2 案例
2.2 課程案例
- 最初的課程接口有兩個職責，耦合過大
-
單一職責原則（Single Responsibility Principle，SRP）（上）1 簡介2 案例 - 按職責拆分
-
單一職責原則（Single Responsibility Principle，SRP）（上）1 簡介2 案例 -
單一職責原則（Single Responsibility Principle，SRP）（上）1 簡介2 案例