單一職責原則
1.1 我是“牛”類，我可以擔任多職嗎
單一職責原則，英文名稱是Single Responsibility Principle，簡稱是SRP，定義是應該有且僅有一個原因引起類的變更，
什么是類的職責，以及怎么劃分類的職責？
舉例：rbac模型
這個介面設計的存在問題：用戶屬性和用戶行為沒有分開
把用戶資訊抽取成一個BO（Business Object，業務物件），把行為抽取成一個Biz（Business Logic，業務邏輯），我們面向介面編程，所以產生的UserInfo物件可以當成IUserBO介面使用，也可以錄成IUserBiz介面使用
IUserInfo userInfo = new UserInfo();
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();
在實際使用中，我們更傾向于使用兩個不同的類或介面，如下：
1.2 絕殺技，打破你的傳統思維
舉例：電話設計
這么設計的問題是IPhone介面不只有一個職責，分別為：一個是協議管理，一個是資料傳送，
這樣設計引起類間耦合過重、類的數量增加，人為地增加了設計的復雜性
這樣設計，一個類實作兩個介面，把兩個職責融合在一個類中，
單一職責原則的好處
實作什么職責都有清晰明確的定義，這樣類的復雜性降低，可讀性提高，可維護性提高
1.3 我單純，所以我快樂
單一職責適用于介面、類，同時也適用于方法，
要修改用戶名稱，就呼叫changeUserName方法；要修改家庭地址，就呼叫changeHomeAddress方法；要修改單位電話，就呼叫changeOfficeTel方法，每個方法的職責非常清晰明確，不僅開發簡單，而且日后的維護也非常容易，
1.4 最佳實踐
大部分情況下類設計都是與單一職責相違背的，類的單一職責受到非常多因素的制約，現實你必須去考慮專案工期、成本、人員技術水平、硬體情況、網路情況甚至有時候還要考慮政府政策、壟斷協議等因素，
對于單一職責原則，建議是介面一定要做到單一職責，類的設計盡量做到只有一個原因引起變化，
參考：
- 《設計模式之禪》第2版
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/523137.html
標籤：設計模式
上一篇：為訪客用戶顯示某些類別的產品價格
下一篇：設計模式之禪01單一職責原則