單一職責原則

乙個類，引起類變化的只有乙個原因。

類只因乙個原因而變化，這彷彿是一種新的類定義方式。當接觸物件導向程式設計時，試圖把乙個類對比為乙個事物，事物具備的功能都是這個類的操作。比如手機，既可以用來打**，也可以用來玩遊戲。而在單一職責原理下，手機的兩個功能就是引起這個類變化的兩個原因，就應該寫成兩個類。

單一職責原則的核心就是控制類的粒度大小、將物件解耦、提高其內聚性。如果遵循單一職責原則將有以下優點。

降低類的複雜度。乙個類只負責一項職責，其邏輯肯定要比負責多項職責簡單得多。

提高類的可讀性。複雜性降低，自然其可讀性會提高。

提高系統的可維護性。可讀性提高，那自然更容易維護了。

變更引起的風險降低。變更是必然的，如果單一職責原則遵守得好，當修改乙個功能時，可以顯著降低對其他功能的影響。

但是該原則提出物件不應該承擔太多職責，如果乙個物件承擔了太多的職責，至少存在以下兩個缺點：

乙個職責的變化可能會削弱或者抑制這個類實現其他職責的能力；

當客戶端需要該物件的某乙個職責時，不得不將其他不需要的職責全都包含進來，從而造成冗餘**或**的浪費。

還有乙個就是如果這個類有很多的動機或者因素來改變它，我們就需要考慮分離它，使它的功能單一化。

總結：1.遵守單一職責原則，盡量將不同的職責封裝到不同的類或模組中。

今天的單一職責模式不太好寫**或者太容易寫出**，我們要根據我們的專案區思考，什麼時候會去用到它，什麼時候是不需要分離類的。作為乙個程式設計師，我們一定要加入自己的思考，而不只是作為乙個**的搬運工。