前方高能：《一故事一設計模式》PDF 電子書已經上線，關注公眾號即可獲取。

個人博客原文：
單一職責原則

設計模式六大原則之一：單一職責原則

簡介

姓名 ：單一職責原則
英文名 ：Single Responsibility Principle
座右銘 ：There should never be more than one reason for a class to change. 應當有且僅有一個原因引起類的變更。。。意思就是不管干啥，我都只干一件事，你叫我去買菜，我就只買菜，叫我順便去倒垃圾就不干了，就這么拽
脾氣 ：一個字“拽”，兩個字“特拽“
伴侶 ：老子職責單一，哪來的伴侶？
個人介紹 ：在這個人兼多責的社會里，我顯得那么的特立獨行，殊不知，現在社會上發生的很多事情都是因為沒有處理好職責導致的，比如，經常有些父母帶著小孩，一邊玩手機，導致小孩弄丟、發生事故等等

單一職責應用范圍

單一職責原則適用的范圍有接口、方法、類。按大家的說法，接口和方法必須保證單一職責，類就不必保證，只要符合業務就行。

方法

設想一下這個場景：假設我們要做一個用戶修改名字以及修改密碼的功能，可以有多種實現方案，比如下面列舉 2 種實現方式
代碼：SrpOfMethod.java

第一種實現方式

/*** 錯誤的示范*/ enum OprType {/*** 更新密碼*/UPDATE_PASSWORD,/*** 更新名字*/UPDATE_NAME; }interface UserOpr {boolean updateUserInfo(User user, OprType oprType); }class UserOprImpl implements UserOpr {@Overridepublic boolean updateUserInfo(User user, OprType oprType) {if (oprType == OprType.UPDATE_NAME) {// update name} else if (oprType == OprType.UPDATE_PASSWORD) {// update password}return true;} }

第二種實現方式

/*** 正確的示范*/ interface UserOpr2 {boolean updatePassword(User user, String password);boolean updateUserInfo(User user); }class UserOprImpl2 implements UserOpr2 {@Overridepublic boolean updatePassword(User user, String password) {user.setPassword(password);// update passwordreturn true;}@Overridepublic boolean updateUserInfo(User user) {// update user inforeturn true;} }

2 種實現有什么區別呢？ 第一種實現通過 OprType 類型的不同來做不同的事情，把修改密碼和修改名字耦合在一起，容易引起問題，只要稍不注意，傳錯枚舉值就悲劇了，在代碼中也沒法很直接看到是做什么操作，也就是這個方法的職責不明確。而第二種實現，把修改密碼和修改名字分離開來，也就是把修改密碼和修改名字都當做獨自的職責處理，這樣子就很清晰明了，你調用哪個方法，就很明確的知道這個方法是實現什么邏輯。結論是啥呢？用第二種方式實習才符合單一職責原則?，F實中看到很多像第一種實現的代碼，而且是枚舉有十來個的情況，看代碼真費勁。

接口

設想一下這個場景，假設我們讓小明去倒垃圾，小紅去買菜，小紅回來后再叫小紅去洗碗。下面也舉 2 個實現的例子。
代碼：SrpOfInterface.java

第一種實現方式

/*** 錯誤的示范*/ interface Housework {void shopping();void pourGarbage(); }class XiaoMing implements Housework {@Overridepublic void shopping() {// 不購物}@Overridepublic void pourGarbage() {System.out.println("pourGarbage ...");} }class XiaoHong implements Housework {@Overridepublic void shopping() {System.out.println("shopping ...");}@Overridepublic void pourGarbage() {// 從不倒垃圾} }

中途回來小紅去洗碗，要怎么實現？按這個寫法，就在 Housework 接口添加 washingUp() 方法，然后小明和小紅依次都實現洗碗這個方法，只是小明不做具體實現代碼，這樣子是不是覺得很別扭，不符合單一職責原則的，修改一個地方，不影響其他不需要改變的地方，只對需要用到的地方做修改。小明本來就不用洗碗，卻要去實現洗碗這個方法。

第二種實現方式

/*** 正確的示范*/ interface Shopping {void doShopping(); }interface PourGarbage {void doPourGarbage(); }interface WashingUp {void doWashingUp(); }class XiaoMing2 implements PourGarbage {@Overridepublic void doPourGarbage() {System.out.println("pourGarbage ...");} }class XiaoHong2 implements Shopping, WashingUp {@Overridepublic void doShopping() {System.out.println("shopping ...");}@Overridepublic void doWashingUp() {System.out.println("washing up ...");} }

可以看到，這種實現把不同的家務都當做不同的職責，分離開來，這種實現可以按需實現做家務的類型，小明只需要去倒垃圾，就實現 PourGarbage 接口，小紅去購物和洗碗，就實現 Shopping 和 WashingUp 接口，完全不會影響到對方，這才是完美的根據單一職責原則編寫出來的代碼。

類

類這個看了一些資料都說沒法硬性要求一定按單一職責原則分，或者說類的職責可大可小，沒有很明確的像上面接口那樣按照單一職責原則分就很清晰也很有道理。
設想一下這個場景：我們要實現一個用戶注冊、登錄、注銷操作，可以像如下 2 種實現方式
代碼：SrpOfClass.java

第一種實現方式

從用戶的角度考慮，這些操作都是用戶的行為，可以放在一個統一的類 UserBiz

class UserBiz {public boolean register(User user){// 注冊操作return true;}public boolean login(User user) {// 登錄操作return true;}public boolean logout(User user) {// 注銷操作return true;}}

第二種實現方式

有人又說，不是說單一職責么？從業務操作考慮，需要把注冊、登錄、注銷分開

class UserRegisterBiz {public boolean register(User user){// 注冊操作return true;}}class UserLoginBiz {public boolean login(User user) {// 登錄操作return true;}}class UserLogoutBiz {public boolean logout(User user) {// 注銷操作return true;}}

感覺像是在抬杠，其實這個沒有好壞之分，根據具體業務具體分析，你說你的登錄、注冊、注銷操作代碼很多，需要分開，那就分開，無可厚非。

好處

類的復雜性降低，實現什么職責都有清晰明確的定義

可讀性提高，復雜性降低，那當然可讀性提高了

可維護性提高，可讀性提高，那當然更容易維護了

變更引起的風險降低，變更是必不可少的，如果接口的單一職責做得好，一個接口修改只對相應的實現類有影響，對其他的接口無影響，這對系統的擴展性、維護性都有非常大的幫助
(來自《設計模式之禪》)

總結

這個單一職責原則，目的就是提高代碼的可維護性、可讀性、擴展性，如果為了單一職責而破壞了這 3 個特性，可能會得不償失。

參考資料：《大話設計模式》、《Java設計模式》、《設計模式之禪》、《研磨設計模式》、《Head First 設計模式》

希望文章對您有所幫助，設計模式系列會持續更新，感興趣的同學可以關注公眾號，第一時間獲取文章推送閱讀，也可以一起交流，交個朋友。

公眾號之設計模式系列文章

總結

以上是生活随笔為你收集整理的单一职责原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。