設計模式之Chain of Responsibility(職責鏈)

Chain of Responsibility 定義
Chain of Responsibility(CoR) 是用一系列類別 (classes) 試圖處理一個請求 request, 這些類別之間是一個鬆散的耦合 , 唯一共同點是在他們之間傳遞 request 。 也就是說，來了一個請求， A 類別先處理，如果沒有處理，就傳遞到 B 類別處理，如果沒有處理，就傳遞到 C 類別處理，就這樣象一個鏈條 (chain) 一樣傳遞下去。

如何使用 ?
雖然這一段是如何使用 CoR, 但是也是演示什麽是 CoR 。

有一個 Handler 介面 :

public interface Handler{
　　 public void handleRequest();
}

這是一個處理 request 的事例， 如果有多種 request, 比如 請求幫助 請求列印 或請求格式化：

最先想到的解決方案是：在介面中增加多個請求：
public interface Handler{
　　 public void handleHelp();
　　 public void handlePrint();
　　 public void handleFormat();

}

具體是一段實現介面 Handler 代碼：
public class ConcreteHandler implements Handler{
　　 private Handler successor;

　　 public ConcreteHandler(Handler successor){
　　 this.successor=successor;
}

　　 public void handleHelp(){
　　　　 // 具體處理請求 Help 的代碼
　　　　 ...
　　 }

　　 public void handlePrint(){
　　　　 // 如果是 print 轉去處理 Print
　　　　 successor.handlePrint();
　　 }
　　 public void handleFormat(){
　　　　 // 如果是 Format 轉去處理 format
　　　　 successor.handleFormat();
　　 }

}
一共有三個這樣的具體實現類別，上面是處理 help, 還有處理 Print 處理 Format 這大概是我們最常用的編程思路。

雖然思路簡單明瞭，但是有一個擴展問題，如果我們需要再增加一個請求 request 種類 , 需要修改介面及其每一個實現。

第二方案 : 將每種 request 都變成一個介面，因此我們有以下代碼 ：

public interface HelpHandler{
　　 public void handleHelp();
}

public interface PrintHandler{
　　 public void handlePrint();
}

public interface FormatHandler{
　　 public void handleFormat();
}

public class ConcreteHandler
　　 implements HelpHandler,PrintHandler,FormatHandlet{
　　 private HelpHandler helpSuccessor;
　　 private PrintHandler printSuccessor;
　　 private FormatHandler formatSuccessor;

　　 public ConcreteHandler(HelpHandler helpSuccessor,PrintHandler printSuccessor,FormatHandler 　　　　　　　　　　　　 formatSuccessor)
　　 {
　　　　 this.helpSuccessor=helpSuccessor;
　　　　 this.printSuccessor=printSuccessor;
　　　　 this.formatSuccessor=formatSuccessor;
　　 }

　　 public void handleHelp(){
　　　　 .......
　　 }

　　 public void handlePrint(){this.printSuccessor=printSuccessor;}

　　 public void handleFormat(){this.formatSuccessor=formatSuccessor;}

}

這個辦法在增加新的請求 request 情況下，只是節省了介面的修改量，介面實現 ConcreteHandler 還需要修改。而且代碼顯然不簡單美麗。

解決方案 3: 在 Handler 介面中只使用一個參數化方法：
public interface Handler{
　　 public void handleRequest(String request);
}
那麽 Handler 實現代碼如下：
public class ConcreteHandler implements Handler{
　　 private Handler successor;

　　 public ConcreteHandler(Handler successor){
　　　　 this.successor=successor;
　　 }

　　 public void handleRequest(String request){
　　　　 if (request.equals("Help")){
　　　　　　 // 這裏是處理 Help 的具體代碼
　　　　 }else
　　　　　　 // 傳遞到下一個
　　　　　　 successor.handle(request);

　　　　 }
　　 }

}

這裏先假設 request 是 String 類型，如果不是怎麽辦？當然我們可以創建一個專門類別 Request

最後解決方案 : 介面 Handler 的代碼如下：
public interface Handler{
　　 public void handleRequest(Request request);
}
Request 類別的定義 :
public class Request{
　　 private String type;

　　 public Request(String type){this.type=type;}

　　 public String getType(){return type;}

　　 public void execute(){
　　　　 //request 真正具體行爲代碼
　　 }
}
那麽 Handler 實現代碼如下：
public class ConcreteHandler implements Handler{
　　 private Handler successor;

　　 public ConcreteHandler(Handler successor){
　　　　 this.successor=successor;
　　 }

　　 public void handleRequest(Request request){
　　　　 if (request instanceof HelpRequest){
　　　　　　 // 這裏是處理 Help 的具體代碼
　　　　 }else if (request instanceof PrintRequst){
　　　　　　 request.execute();
　　　　 }else
　　　　　　 // 傳遞到下一個
　　　　　　 successor.handle(request);

　　　　 }
　　 }

}

這個解決方案就是 CoR, 在一個鏈上 , 都有相應職責的類別 , 因此叫 Chain of Responsibility 。

CoR 的優點：
因爲無法預知來自外界的請求是屬於哪種類型，每個類別如果碰到它不能處理的請求只要放棄就可以。無疑這降低了類別之間的耦合性。

缺點是效率低，因爲一個請求的完成可能要遍曆到最後才可能完成，當然也可以用樹的概念優化。 在 Java AWT1.0 中，對於滑鼠按鍵事情的處理就是使用 CoR, 到 Java.1.1 以後，就使用 Observer 代替 CoR

擴展性差，因爲在 CoR 中，一定要有一個統一的介面 Handler. 局限性就在這裏。