Java PatternDesign of GOF(四人幫力作，享譽15年)第十五模式

Java PatternDesign of GOF(四人幫力作，享譽15年)

第十五模式

板橋里人 http://www.jdon.com 2002/04/21(轉載請保留)

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.局限性就在這里。

與Command模式區別：

Command 模式需要事先協商客戶端和服務器端的調用關系，比如 1 代表 start 2 代表 move 等，這些 都是封裝在 request 中，到達服務器端再分解。

CoR 模式就無需這種事先約定，服務器端可以使用 CoR 模式進行客戶端請求的猜測，一個個猜測 試驗。

總結

以上是生活随笔為你收集整理的java 四人帮,Java PatternDesign of GOF(四人帮巨著，享誉15年)第十五模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。