23種設計模式-責任鏈模式

定義:使多個對象都有機會處理請求,從而避免了請求的發送者和接收者之間的耦合關係。將這些對象連成一條鏈,並沿着這條鏈傳遞該請求,直到有對象處理它爲止。

類型:行爲類模式

類圖:

        首先來看一段代碼:

  1. public void test(int i, Request request){  
  2.     if(i==1){  
  3.         Handler1.response(request);  
  4.     }else if(i == 2){  
  5.         Handler2.response(request);  
  6.     }else if(i == 3){  
  7.         Handler3.response(request);  
  8.     }else if(i == 4){  
  9.         Handler4.response(request);  
  10.     }else{  
  11.         Handler5.response(request);  
  12.     }  
  13. }  

       代碼的業務邏輯是這樣的,方法有兩個參數:整數i和一個請求request,根據i的值來決定由誰來處理request,如果i==1,由Handler1來處理,如果i==2,由Handler2來處理,以此類推。在編程中,這種處理業務的方法非常常見,所有處理請求的類有if…else…條件判斷語句連成一條責任鏈來對請求進行處理,相信大家都經常用到。這種方法的優點是非常直觀,簡單明瞭,並且比較容易維護,但是這種方法也存在着幾個比較令人頭疼的問題:

  • 代碼臃腫:實際應用中的判定條件通常不是這麼簡單地判斷是否爲1或者是否爲2,也許需要複雜的計算,也許需要查詢數據庫等等,這就會有很多額外的代碼,如果判斷條件再比較多,那麼這個if…else…語句基本上就沒法看了。
  • 耦合度高:如果我們想繼續添加處理請求的類,那麼就要繼續添加else if判定條件;另外,這個條件判定的順序也是寫死的,如果想改變順序,那麼也只能修改這個條件語句。

        既然缺點我們已經清楚了,就要想辦法來解決。這個場景的業務邏輯很簡單:如果滿足條件1,則由Handler1來處理,不滿足則向下傳遞;如果滿足條件2,則由Handler2來處理,不滿足則繼續向下傳遞,以此類推,直到條件結束。其實改進的方法也很簡單,就是把判定條件的部分放到處理類中,這就是責任連模式的原理。

 

責任連模式的結構

        責任連模式的類圖非常簡單,它由一個抽象地處理類和它的一組實現類組成:

  • 抽象處理類:抽象處理類中主要包含一個指向下一處理類的成員變量nextHandler和一個處理請求的方法handRequest,handRequest方法的主要主要思想是,如果滿足處理的條件,則有本處理類來進行處理,否則由nextHandler來處理。
  • 具體處理類:具體處理類主要是對具體的處理邏輯和處理的適用條件進行實現。

        瞭解了責任連模式的大體思想之後,再看代碼就比較好理解了:

  1. class Level {  
  2.     private int level = 0;  
  3.     public Level(int level){  
  4.         this.level = level;  
  5.     };  
  6.       
  7.     public boolean above(Level level){  
  8.         if(this.level >= level.level){  
  9.             return true;  
  10.         }  
  11.         return false;  
  12.     }  
  13. }  
  14.   
  15. class Request {  
  16.     Level level;  
  17.     public Request(Level level){  
  18.         this.level = level;  
  19.     }  
  20.       
  21.     public Level getLevel(){  
  22.         return level;  
  23.     }  
  24. }  
  25.   
  26. class Response {  
  27.   
  28. }  
  29.   
  30. abstract class Handler {  
  31.     private Handler nextHandler;      
  32.     public final Response handleRequest(Request request){  
  33.         Response response = null;  
  34.           
  35.         if(this.getHandlerLevel().above(request.getLevel())){  
  36.             response = this.response(request);  
  37.         }else{  
  38.             if(this.nextHandler != null){  
  39.                 this.nextHandler.handleRequest(request);  
  40.             }else{  
  41.                 System.out.println("-----沒有合適的處理器-----");  
  42.             }  
  43.         }  
  44.         return response;  
  45.     }  
  46.     public void setNextHandler(Handler handler){  
  47.         this.nextHandler = handler;  
  48.     }  
  49.     protected abstract Level getHandlerLevel();  
  50.     public abstract Response response(Request request);  
  51. }  
  52.   
  53. class ConcreteHandler1 extends Handler {  
  54.     protected Level getHandlerLevel() {  
  55.         return new Level(1);  
  56.     }  
  57.     public Response response(Request request) {  
  58.         System.out.println("-----請求由處理器1進行處理-----");  
  59.         return null;  
  60.     }  
  61. }  
  62.   
  63. class ConcreteHandler2 extends Handler {  
  64.     protected Level getHandlerLevel() {  
  65.         return new Level(3);  
  66.     }  
  67.     public Response response(Request request) {  
  68.         System.out.println("-----請求由處理器2進行處理-----");  
  69.         return null;  
  70.     }  
  71. }  
  72.   
  73. class ConcreteHandler3 extends Handler {  
  74.     protected Level getHandlerLevel() {  
  75.         return new Level(5);  
  76.     }  
  77.     public Response response(Request request) {  
  78.         System.out.println("-----請求由處理器3進行處理-----");  
  79.         return null;  
  80.     }  
  81. }  
  82.   
  83. public class Client {  
  84.     public static void main(String[] args){  
  85.         Handler handler1 = new ConcreteHandler1();  
  86.         Handler handler2 = new ConcreteHandler2();  
  87.         Handler handler3 = new ConcreteHandler3();  
  88.   
  89.         handler1.setNextHandler(handler2);  
  90.         handler2.setNextHandler(handler3);  
  91.           
  92.         Response response = handler1.handleRequest(new Request(new Level(4)));  
  93.     }  
  94. }  

       代碼中Level類是模擬判定條件;Request,Response分別對應請求和響應;抽象類Handler中主要進行條件的判斷,這裏模擬一個處理等級,只有處理類的處理等級高於Request的等級才能處理,否則交給下一個處理者處理。在Client類中設置好鏈的前後執行關係,執行時將請求交給第一個處理類,這就是責任連模式,它完成的功能與前文中的if…else…語句是一樣的。

 

責任鏈模式的優缺點

        責任鏈模式與if…else…相比,他的耦合性要低一些,因爲它把條件判定都分散到了各個處理類中,並且這些處理類的優先處理順序可以隨意設定。責任鏈模式也有缺點,這與if…else…語句的缺點是一樣的,那就是在找到正確的處理類之前,所有的判定條件都要被執行一遍,當責任鏈比較長時,性能問題比較嚴重。

 

責任鏈模式的適用場景

       就像開始的例子那樣,假如使用if…else…語句來組織一個責任鏈時感到力不從心,代碼看上去很糟糕時,就可以使用責任鏈模式來進行重構。

 

總結

       責任鏈模式其實就是一個靈活版的if…else…語句,它就是將這些判定條件的語句放到了各個處理類中,這樣做的優點是比較靈活了,但同樣也帶來了風險,比如設置處理類前後關係時,一定要特別仔細,搞對處理類前後邏輯的條件判斷關係,並且注意不要在鏈中出現循環引用的問題。

發佈了32 篇原創文章 · 獲贊 9 · 訪問量 5萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章