1、單一職責原則的概念
Single Responsibility Principle，SRP：
一個類被改變的原因不能超過一個，也就是說，一個類只有一個職責，如果職責過多，代碼就會臃腫，可讀性更差，也更難以維護。其實上單一職責原則和接口隔離原則有一定的關係，接口隔離以後，職責就單一了，實現這個接口的類的職責自然也就單一了。但是接口隔離關注的是抽象層，單一職責關注的是兩者兼而有之，偏重於實現。
2、為什麼要遵守單一職責原則
1、提高類的可維護性和可讀寫性
一個類的職責少了，複雜度降低了，代碼就少了，可讀性也就好了，可維護性自然就高了。
2、提高系統的可維護性
系統是由類組成的，每個類的可維護性高，相對來講整個系統的可維護性就高。當然，前提是系統的架構沒有問題。
3、降低變更的風險
一個類的職責越多，變更的可能性就更大，變更帶來的風險也就越大，
3、如何遵守單一職責原則
合理的職責分解相同的職責放到一起，不同的職責分解到不同的接口和實現中去，這個是最容易也是最難運用的原則，關鍵還是要從業務出發，從需求出發，識別出同一種類型的職責。舉個例子：人的行為分析，包括了生理、生活和工作等行為的分析，生理行為包括吃、跑、睡等行為，生活行為包括穿衣等行為，工作行為包括上下班，開會等行為，如下圖所示：
圖1 人類行為分析示例
人類的行為分成了三個接口：生理行為接口、工作行為接口和生活行為接口，以及三個實現類。如果都用一個實現類來承擔這三個接口的職責，就會導致代碼臃腫，不易維護，如果以後再加上其他行為，例如學習行為接口，將會產生變更風險（這裡還用到了組合模式，以後會詳細說明）。
四、最佳實踐
在實際工作中，有一個經常會用到的設計模式，DAO模式，又叫數據訪問對象，裡面定義了資料庫中表的增、刪、改、查操作，按照單一職責原則，為什麼不把增、刪、改、查分別定義成四種接口？這是因為資料庫的表操作，基本上就是這四種類型，不可能變化，所以沒有必要分開定義，反而經常變化的是資料庫的表結構，表結構一變，這四種操作都要跟著變。所以通常我們會針對一張表實現一個DAO，一張表就代表一種類型的職責。