1.1 我是“?！鳖悾铱梢該味嗦殕?/h3>

單一職責原則的英文名稱是Single Responsibility Principle，簡稱是SRP。這個設計原則備受爭議，只要你想和別人爭執、慪氣或者是吵架，這個原則是屢試不爽的。如果你是老大，看到一個接口或類是這樣或那樣設計的，你就問一句：“你設計的類符合SRP原則嗎？”保準對方立馬“萎縮”掉，而且還一臉崇拜地看著你，心想：“老大確實英明”。這個原則存在爭議之處在哪里呢？就是對職責的定義，什么是類的職責，以及怎么劃分類的職責。我們先舉個例子來說明什么是單一職責原則。

只要做過項目，肯定要接觸到用戶、機構、角色管理這些模塊，基本上使用的都是RBAC模型（Role-Based Access Control，基于角色的訪問控制，通過分配和取消角色來完成用戶權限的授予和取消，使動作主體（用戶）與資源的行為（權限）分離），確實是一個很好的解決辦法。我們這里要講的是用戶管理、修改用戶的信息、增加機構（一個人屬于多個機構）、增加角色等，用戶有這么多的信息和行為要維護，我們就把這些寫到一個接口中，都是用戶管理類嘛，我們先來看它的類圖，如圖1-1所示。

圖1-1 用戶信息維護類圖

太Easy的類圖了，我相信，即使是一個初級的程序員也可以看出這個接口設計得有問題，用戶的屬性和用戶的行為沒有分開，這是一個嚴重的錯誤！這個接口確實設計得一團糟，應該把用戶的信息抽取成一個BO（Bussiness Object，業務對象），把行為抽取成一個Biz（Business Logic，業務邏輯），按照這個思路對類圖進行修正，如圖1-2所示。

重新拆封成兩個接口，IUserBO負責用戶的屬性，簡單地說，IUserBO的職責就是收集和反饋用戶的屬性信息；IUserBiz負責用戶的行為，完成用戶信息的維護和變更。各位可能要說了，這個與我實際工作中用到的User類還是有差別的呀！別著急，我們先來看一看分拆成兩個接口怎么使用。OK，我們現在是面向接口編程，所以產生了這個UserInfo對象之后，當然可以把它當IUserBO接口使用。也可以當IUserBiz接口使用，這要看你在什么地方使用了。要獲得用戶信息，就當是IUserBO的實現類；要是希望維護用戶的信息，就把它當作IUserBiz的實現類就成了，如代碼清單1-1所示。

圖1-2 職責劃分后的類圖

代碼清單1-1 分清職責后的代碼示例

.......
IUserBiz userInfo=new UserInfo();
//我要賦值了，我就認為它是一個純粹的BO
IUserBO userBO=(IUserBO)userInfo;
userBO.setPassword("abc");
//我要執行動作了，我就認為是一個業務邏輯類
IUserBiz userBiz=(IUserBiz)userInfo;
userBiz.deleteUser();
.......

確實可以如此，問題也解決了，但是我們來分析一下剛才的動作，為什么要把一個接口拆分成兩個呢？其實，在實際的使用中，我們更傾向于使用兩個不同的類或接口：一個是IUserBO，一個是IUserBiz，類圖如圖1-3所示。

以上我們把一個接口拆分成兩個接口的動作，就是依賴了單一職責原則，那什么是單一職責原則呢？單一職責原則的定義是：應該有且僅有一個原因引起類的變更。

圖1-3 項目中經常采用的SRP類圖