想要精通設計模式，必須要先搞清楚設計模式的六大原則。

在開始設計模式之前，先來談談設計模式的六大設計原則，第一個便是單一職責原則(Single Responsibility Principle)了。

單一職責原則定義

There should never be more than one reason for a class to change.

這句話意思很簡單，不應該存在多於一個導致類變更的原因。通俗來說就是，一個類應該只有一項職責，不會有多個原因導致類發生變更。

問題由來

我們設計這樣一個介面

public interface
 
 IUserInfo {
    void setUsername();
    void changePassword();
}

很明顯看到這樣一個介面，誰都會覺得有問題，使用者屬性怎麼可以和使用者行為放在一起。肯定應該是使用者屬性放一起，使用者行為放一起啊。

單一職責解決問題

對啊，根據這樣的想法，我們把剛剛的介面拆成兩個介面。

public interface IUserInfo {
    void setUsername();
}

public interface IUserBiz {
    void changePassword();
}

其實這就是單一職責原則。
有人可能就要說了，這也太簡單了吧。對啊，對於一個從未接觸過設計模式的小白來說，在設計介面的時候，都會去這麼設計的。
是啊，真的很簡單，可是有時候卻又十分的難去實現，因為職責的劃分很難，就比如手機打電話來說

public interface Iphone {
    void dial(String phoneNumber);
    void chat(Object o);
    void hangup();

}

這裡我們定義一個手機介面，我們來劃分職責，接通和結束通話應該是通訊協議上的，而聊電話則是資料傳輸。那按照單一原則來說，我們應該給它們也拆到兩個介面中去，但是拆開之後呢，我們會發現，當我想打電話的時候我需要將他們再組裝到一起，這樣反而是增加了系統的複雜度，我想平時遇到類似情況的時候，我們都是放在一個介面中的。

另一方面，職責擴散，就是由於某種原因，導致原來單一的職責變成了若干了更細粒度的職責。這時候如果再去拆分，代價還是比較高的。

優點

單一職責原則會有以下優點：

1. 降低了類的複雜度，實現什麼職責都有清晰明確的定義。
2. 提高了可讀性。
3. 提高了可維護性。
4. 變更引起的風險降低，變更是必不可少的，如果介面的單一職責做得好，一個介面修改只對相應的實現類有影響，對其他的介面無影響，這對系統的擴充套件性、維護性都有非常大的幫助。

總結

看到過大佬有這樣的說法，只有邏輯足夠簡單，才可以在方法級別上違反單一職責原則，只有類中方法數量足夠少，才可以在類級別上違反單一職責原則。

單一職責原則看起來很簡單，做起來卻很難，單一職責原則提出了一個編寫程式的標準，用“職責”或“變化原因”來衡量介面或類的設計是否優良，但是“職責”和“變化原因”都是不可度量的，因專案而異，因環境而異。

因此對於單一職責原則，我的建議是介面一定要做到單一職責，類的設計儘量做到只有一個原因引起變化。