單一職責原則：一個類，只有一個引起它變化的原因。
為什麼需要單一職責原則？
如果一個類有多個原因要去修改它，那麼修改一個功能時，可能會讓其他功能產生Bug，所以一個類最好只有一個職責。但實際應用中還是比較難實現的，我們只能是盡量符合這個原則。
有時候，開發人員設計接口的時候會有些問題，比如用戶的屬性和用戶的行為被放在一個接口中聲明。這就造成了業務對象和業務邏輯被放在了一起，這樣就造成了這個接口有兩種職責，接口職責不明確，按照SRP的定義就違背了接口的單一職責原則了。
下面是個例子：
package com.loulijun.chapter1; public interface Itutu { //身高void setShengao(double height); double getShengao(); //體重void setTizhong(double weight); double getTizhong(); //吃飯boolean chiFan(boolean hungry); //上網boolean shangWang(boolean silly); }上面的例子就存在這個問題，身高、體重屬於業務對象，與之相應的方法主要負責用戶的屬性。而吃飯、上網是相應的業務邏輯，主要負責用戶的行為。但是這就會給人一種不知道這個接口到底是做什麼的感覺，職責不清晰，後期維護的時候也會造成各種各樣的問題。
解決辦法：單一職責原則，將這個接口分解成兩個職責不同的接口即可
ItutuBO.java：負責tutu（塗塗，假如是個人名）的屬性
package com.loulijun.chapter1; /** * BO：Bussiness Object，業務對象* 負責用戶的屬性* @author Administrator * */ public interface ItutuBO { //身高void setShengao(double height); double getShengao(); //體重void setTizhong(double weight); double getTizhong(); }ItutuBL.java：負責塗塗的行為
package com.loulijun.chapter1; /** * BL:Business Logic,業務邏輯* 負責用戶的行為* @author Administrator * */ public interface ItutuBL { //吃飯boolean chiFan(boolean hungry); //上網boolean shangWang(boolean silly); }這樣就實現了接口的單一職責。那麼實現接口的時候，就需要有兩個不同的類
TutuBO.java
package com.loulijun.chapter1; public class TutuBO implements ItutuBO { private double height; private double weight; @Override public double getShengao() { return height; } @Override public double getTizhong() { return weight; } @Override public void setShengao(double height) { this.height = height; } @Override public void setTizhong(double weight) { this.weight = weight; } }TutuBL.java
package com.loulijun.chapter1; public class TutuBL implements ItutuBL { @Override public boolean chiFan(boolean hungry) { if(hungry) { System.out.println("去吃火鍋..."); return true; } return false; } @Override public boolean shangWang(boolean silly) { if(silly) { System.out.println("好無聊啊，上會網..."); return true; } return false; } }這樣就清晰了，當需要修改用戶屬性的時候只需要對ItutuBO這個接口來修改，只會影響到TutuBO這個類，不會影響其他類。
總結：
1. 實際情況是，很多時候我們無法提前預見“引起變化的原因”，所以我們只能憑經驗構造我們的接口，盡量做到一個接口只有一個職責。這裡說的是接口，類可能會有繼承和實現多個接口，更加難以實現單一職責。
2. 當以前寫的類已經有多個引起變化的原因時，我們最好做代碼重構。
但是、使用單一職責原則有一個問題，“職責”沒有一個明確的劃分標準，如果把職責劃分的太細的話會導致接口和實現類的數量劇增，反而提高了複雜度，降低了代碼的可維護性。所以使用這個職責的時候還要具體情況具體分析。建議就是接口一定要採用單一職責原則，實現類的設計上盡可能做到單一職責原則，最好是一個原因引起一個類的變化。