單一職責原則（Single Responsibility Principle，簡稱SRP）類的職責要單一，不能將太多的職責放在一個類中（高內聚、低耦合）。簡單來說就是不同的功能封裝在不同的類中，使用的時候提供接口就可以了，比如常做的登錄時的驗證功能（手機號的位數，密碼限制位數），就可以單獨封裝在一個類中。

定義：

一個對象應該只包含單一的職責，并且該職責被完整地封裝在一個類中，即又定義有且僅有一個原因使類變更。（甲類負責兩個不同的職責：職責A，職責B。當由于職責A需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責B功能發生故障。也就是說職責A和B被耦合在了一起”）

原因分析：

1) 一個類（或者大到模塊，小到方法）承擔的職責越多，它被復用的可能性越小，而且如果一個類承擔的職責過多，就相當于將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作。

2) 類的職責主要包括兩個方面：數據職責和行為職責，數據職責通過其屬性來體現，而行為職責通過其方法來體現。

3) 單一職責原則是實現高內聚、低耦合的指導方針，在很多代碼重構手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責并將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗。

優點：

1、降低類的復雜性，類的職責清晰明確。比如數據職責和行為職責清晰明確。

2、提高類的可讀性和維護性。

3、變更引起的風險減低，變更是必不可少的，如果接口的單一職責做得好，一個接口修改只對相應的類有影響，對其他接口無影響，這對系統的擴展性、維護性都有非常大的幫助。

注意：

單一職責原則提出了一個編寫程序的標準，用“職責”或“變化原因”來衡量接口或類設計得是否合理，但是“職責”和“變化原因”都是沒有具體標準的，一個類到底要負責那些職責？這些職責怎么細化？細化后是否都要有一個接口或類？這些都需從實際的情況考慮。因項目而異，因環境而異。