設計模式總共有六大基本原則，統稱為SOLID （穩定）原則，分別是S-單一職責原則(Single Responsibility Principle)， O-開閉原則(Open closed Principle)，L-裏氏替換原則(Liskov Substitution Principle)，L-迪米特法則(Law of Demeter)，I-接口隔離原則(Interface Segregation Principle)，D-依賴倒置原則(Dependence Invension Principle)。

S-單一職責原則(Single Responsibility Principle)

一、定義

　　應該有且僅有一個原因引起類的變更。(There should never be more than one reason for a class to change.)

二、理解

　　一個接口或類只有一個職責，它只負責幹一件事，也就是只有一個原因引起它的變化。單一職責原則提出了一個編寫代碼的標準，用"職責"或"變化原因"來判斷一個接口或類是否設計優良，但"職責"和“變化原因”都是不可度量的，因項目而異，因環境而異。

　　如上，圖1-1的IUserInfo接口包含了多個職責，職責不分明，所以可拆分成用負責戶屬性和負責用戶行為兩個職責。職責分離，當有一天需要修改負責用戶屬性這個職責時，並不用擔心影響到用戶行為這個職責，這就是單一職責的好處。

三、優缺點

　　優點：

　　1. 單一職責，復雜性降低

　　2. 可讀性提高

　　3. 可維護性提高

　　4. 變更的風險降低，如果一個接口的單一職責做的好，修改接口只對相應的實現類有影響，對其他接口無影響，這對系統的

　　 擴展性和維護性都有非常大的幫助

　　缺點：

　　暫無

四、 註意事項

　　單一職責原則提出了一個編寫程序的標準，用“職責”或“變化原因”來衡量接口或類設計是否優良，但是“職責”和“變化原因”都是不可度量的，因項目而異，因環境而異。

　　對於接口，我們在設計的時候一定要做到單一，但是對於實現類就需要多方面考慮了。生搬硬套單一職責原則會引起類的劇增，給維護帶來非常多的麻煩，而且過分細分類的職責，會認為的增加系統的復雜性。本來一個類可以實現的行為硬要拆分成兩個類，然後再使用聚合或組合的方式耦合再一起，人為制造了系統的復雜性。

　　建議：接口一定要做到單一職責，類的設計盡量做到只有一個原因引起變化。

學習資料：

《設計模式之禪》秦小波 著

單一職責原則

學習設計模式 - 六大基本原則之單一職責原則