快捷導航

簡單講解Java設(shè)計模式編程中的單一職責原則

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

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

單一職責原則：一個類，只有一個引起它變化的原因。

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

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

下面是個例子：

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); 
}

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

解決辦法：單一職責原則，將這個接口分解成兩個職責不同的接口即可

ItutuBO.java：負責tutu（涂涂，假如是個人名）的屬性

package com.loulijun.chapter1; 
  
/** 
 * BO：Bussiness Object，業(yè)務(wù)對象 
 * 負責用戶的屬性 
 * @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,業(yè)務(wù)邏輯 
 * 負責用戶的行為 
 * @author Administrator 
 * 
 */ 
public interface ItutuBL { 
  //吃飯 
  boolean chiFan(boolean hungry); 
  //上網(wǎng) 
  boolean shangWang(boolean silly); 
}

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

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ǎng)..."); 
      return true; 
    } 
    return false; 
  } 
  
}

這樣就清晰了，當需要修改用戶屬性的時候只需要對ItutuBO這個接口來修改，只會影響到TutuBO這個類，不會影響其他類。

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

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

您可能感興趣的文章: