單一職責原則（Single Responsibility Principle），簡稱SRP。
定義：
There should never be more than one reason for a class to change.
應該有且僅有一個原因引起類的變更。
有時候，開發人員設計接口的時候會有些問題，比如用戶的屬性和用戶的行為被放在一個接口中聲明。這就造成了業務對象和業務邏輯被放在了一起，這樣就造成了這個接口有兩種職責，接口職責不明確，按照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,業務邏輯
* 負責用戶的行為www.2cto.com
* @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、提高可讀性
3、提高可維護性
4、降低變更引起的風險，對系統擴展性和維護性很有幫助
但是、使用單一職責原則有一個問題，“職責”沒有一個明確的劃分標准，如果把職責劃分的太細的話會導致接口和實現類的數量劇增，反而提高了復雜度，降低了代碼的可維護性。所以使用這個職責的時候還要具體情況具體分析。建議就是接口一定要采用單一職責原則，實現類的設計上盡可能做到單一職責原則，最好是一個原因引起一個類的變化。
作者 婁立軍
作者
