姓名 ：單一職責原則
英文名 ：Single Responsibility Principle
座右銘 ：There should never be more than one reason for a class to change. 應當有且僅有一個原因引起類的變更。。。意思就是不管幹啥，我都只幹一件事，你叫我去買菜，我就只買菜，叫我順便去倒垃圾就不幹了，就這麼拽
脾氣 ：一個字“拽”，兩個字“特拽“
伴侶 ：老子職責單一，哪來的伴侶?
個人介紹 ：在這個人兼多責的社會裏，我顯得那麼的特立獨行，殊不知，現在社會上發生的很多事情都是因爲沒有處理好職責導致的，比如，經常有些父母帶着小孩，一邊玩手機，導致小孩弄丟、發生事故等等
單一職責應用範圍
單一職責原則適用的範圍有接口、方法、類。按大家的說法，接口和方法必須保證單一職責，類就不必保證，只要符合業務就行。
方法
設想一下這個場景：假設我們要做一個用戶修改名字以及修改密碼的功能，可以有多種實現方案，比如下面列舉 2 種實現方式
代碼：SrpOfMethod.java
第一種實現方式
第二種實現方式
2 種實現有什麼區別呢? 第一種實現通過 OprType 類型的不同來做不同的事情，把修改密碼和修改名字耦合在一起，容易引起問題，只要稍不注意，傳錯枚舉值就悲劇了，在代碼中也沒法很直接看到是做什麼操作，也就是這個方法的職責不明確。而第二種實現，把修改密碼和修改名字分離開來，也就是把修改密碼和修改名字都當做獨自的職責處理，這樣子就很清晰明瞭，你調用哪個方法，就很明確的知道這個方法是實現什麼邏輯。結論是啥呢?用第二種方式實習才符合單一職責原則。現實中看到很多像第一種實現的代碼，而且是枚舉有十來個的情況，看代碼真費勁。
接口
設想一下這個場景，假設我們讓小名去倒垃圾，小紅去買菜，小紅回來後再叫小紅去洗碗。下面也舉 2 個實現的例子。
代碼：SrpOfInterface.java
第一種實現方式
中途回來小紅去洗碗，要怎麼實現?按這個寫法，就在 Housework 接口添加 washingUp() 方法，然後小名和小紅依次都實現洗碗這個方法，只是小名不做具體實現代碼，這樣子是不是覺得很彆扭，不符合單一職責原則的，修改一個地方，不影響其他不需要改變的地方，只對需要用到的地方做修改。小名本來就不用洗碗，卻要去實現洗碗這個方法。
第二種實現方式
可以看到，這種實現把不同的家務都當做不同的職責，分離開來，這種實現可以按需實現做家務的類型，小名只需要去倒垃圾，就實現 PourGarbage 接口，小紅去購物和洗碗，就實現 Shopping 和 WashingUp 接口，完全不會影響到對方，這纔是完美的根據單一職責原則編寫出來的代碼。
類
類這個看了一些資料都說沒法硬性要求一定按單一職責原則分，或者說類的職責可大可小，沒有很明確的像上面接口那樣按照單一職責原則分就很清晰也很有道理。
設想一下這個場景：我們要實現一個用戶註冊、登錄、註銷操作，可以像如下 2 種實現方式
代碼：SrpOfClass.java
第一種實現方式
從用戶的角度考慮，這些操作都是用戶的行爲，可以放在一個統一的類 UserBiz
第二種實現方式
有人又說，不是說單一職責麼?從業務操作考慮，需要把註冊、登錄、註銷分開
感覺像是在擡槓，其實這個沒有好壞之分，根據具體業務具體分析，你說你的登錄、註冊、註銷操作代碼很多，需要分開，那就分開，無可厚非。
好處
類的複雜性降低，實現什麼職責都有清晰明確的定義
可讀性提高，複雜性降低，那當然可讀性提高了
可維護性提高，可讀性提高，那當然更容易維護了
變更引起的風險降低，變更是必不可少的，如果接口的單一職責做得好，一個接口修改只對相應的實現類有影響，對其他的接口無影響，這對系統的擴展性、維護性都有非常大的幫助
(來自《設計模式之禪》)
總結
這個單一職責原則，目的就是提高代碼的可維護性、可讀性、擴展性，如果爲了單一職責而破壞了這 3 個特性，可能會得不償失。
參考資料：《大話設計模式》、《Java設計模式》、《設計模式之禪》、《研磨設計模式》、《Head First 設計模式》