快捷導(dǎo)航

簡(jiǎn)單講解Java設(shè)計(jì)模式編程中的單一職責(zé)原則

更新時(shí)間：2016年02月14日 09:35:36 作者：lixiang0522

這篇文章主要介紹了Java設(shè)計(jì)模式編程中的單一職責(zé)原則,這在團(tuán)隊(duì)開發(fā)編寫接口時(shí)經(jīng)常使用這樣的約定,需要的朋友可以參考下

單一職責(zé)原則：一個(gè)類，只有一個(gè)引起它變化的原因。

為什么需要單一職責(zé)原則？
如果一個(gè)類有多個(gè)原因要去修改它，那么修改一個(gè)功能時(shí)，可能會(huì)讓其他功能產(chǎn)生Bug，所以一個(gè)類最好只有一個(gè)職責(zé)。但實(shí)際應(yīng)用中還是比較難實(shí)現(xiàn)的，我們只能是盡量符合這個(gè)原則。

有時(shí)候，開發(fā)人員設(shè)計(jì)接口的時(shí)候會(huì)有些問(wèn)題，比如用戶的屬性和用戶的行為被放在一個(gè)接口中聲明。這就造成了業(yè)務(wù)對(duì)象和業(yè)務(wù)邏輯被放在了一起，這樣就造成了這個(gè)接口有兩種職責(zé)，接口職責(zé)不明確，按照SRP的定義就違背了接口的單一職責(zé)原則了。

下面是個(gè)例子：

package com.loulijun.chapter1; 
  
public interface Itutu { 
  //身高 
  void setShengao(double height); 
  double getShengao(); 
  //體重 
  void setTizhong(double weight); 
  double getTizhong(); 
  //吃飯 
  boolean chiFan(boolean hungry); 
  //上網(wǎng) 
  boolean shangWang(boolean silly); 
}

上面的例子就存在這個(gè)問(wèn)題，身高、體重屬于業(yè)務(wù)對(duì)象，與之相應(yīng)的方法主要負(fù)責(zé)用戶的屬性。而吃飯、上網(wǎng)是相應(yīng)的業(yè)務(wù)邏輯，主要負(fù)責(zé)用戶的行為。但是這就會(huì)給人一種不知道這個(gè)接口到底是做什么的感覺，職責(zé)不清晰，后期維護(hù)的時(shí)候也會(huì)造成各種各樣的問(wèn)題。

解決辦法：?jiǎn)我宦氊?zé)原則，將這個(gè)接口分解成兩個(gè)職責(zé)不同的接口即可

ItutuBO.java：負(fù)責(zé)tutu（涂涂，假如是個(gè)人名）的屬性

package com.loulijun.chapter1; 
  
/** 
 * BO：Bussiness Object，業(yè)務(wù)對(duì)象 
 * 負(fù)責(zé)用戶的屬性 
 * @author Administrator 
 * 
 */ 
public interface ItutuBO { 
  //身高 
  void setShengao(double height); 
  double getShengao(); 
  //體重 
  void setTizhong(double weight); 
  double getTizhong(); 
}

ItutuBL.java：負(fù)責(zé)涂涂的行為

package com.loulijun.chapter1; 
/** 
 * BL:Business Logic,業(yè)務(wù)邏輯 
 * 負(fù)責(zé)用戶的行為 
 * @author Administrator 
 * 
 */ 
public interface ItutuBL { 
  //吃飯 
  boolean chiFan(boolean hungry); 
  //上網(wǎng) 
  boolean shangWang(boolean silly); 
}

這樣就實(shí)現(xiàn)了接口的單一職責(zé)。那么實(shí)現(xiàn)接口的時(shí)候，就需要有兩個(gè)不同的類

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("好無(wú)聊啊，上會(huì)網(wǎng)..."); 
      return true; 
    } 
    return false; 
  } 
  
}

這樣就清晰了，當(dāng)需要修改用戶屬性的時(shí)候只需要對(duì)ItutuBO這個(gè)接口來(lái)修改，只會(huì)影響到TutuBO這個(gè)類，不會(huì)影響其他類。

總結(jié)：
1. 實(shí)際情況是，很多時(shí)候我們無(wú)法提前預(yù)見“引起變化的原因”，所以我們只能憑經(jīng)驗(yàn)構(gòu)造我們的接口，盡量做到一個(gè)接口只有一個(gè)職責(zé)。這里說(shuō)的是接口，類可能會(huì)有繼承和實(shí)現(xiàn)多個(gè)接口，更加難以實(shí)現(xiàn)單一職責(zé)。
2. 當(dāng)以前寫的類已經(jīng)有多個(gè)引起變化的原因時(shí)，我們最好做代碼重構(gòu)。

但是、使用單一職責(zé)原則有一個(gè)問(wèn)題，“職責(zé)”沒有一個(gè)明確的劃分標(biāo)準(zhǔn)，如果把職責(zé)劃分的太細(xì)的話會(huì)導(dǎo)致接口和實(shí)現(xiàn)類的數(shù)量劇增，反而提高了復(fù)雜度，降低了代碼的可維護(hù)性。所以使用這個(gè)職責(zé)的時(shí)候還要具體情況具體分析。建議就是接口一定要采用單一職責(zé)原則，實(shí)現(xiàn)類的設(shè)計(jì)上盡可能做到單一職責(zé)原則，最好是一個(gè)原因引起一個(gè)類的變化。

您可能感興趣的文章: