明輝手游網(wǎng)中心:是一個免費提供流行視頻軟件教程、在線學(xué)習(xí)分享的學(xué)習(xí)平臺!

設(shè)計模式之Chain of Responsibility

[摘要]Chain of Responsibility定義Chain of Responsibility(CoR) 是用一系列類(classes)試圖處理一個請求request,這些類之間是一個松散的耦合,唯一共同點是在他們之間傳遞request. 也就是說,來了一個請求,A類先處理,如果沒有處理,就傳遞...
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();

}

具體是一段實現(xiàn)接口Handler代碼:
public class ConcreteHandler implements Handler{
  private Handler successor;

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

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

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

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

雖然思路簡單明了,但是有一個擴展問題,如果我們需要再增加一個請求request種類,需要修改接口及其每一個實現(xiàn)。

第二方案:將每種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情況下,只是節(jié)省了接口的修改量,接口實現(xiàn)ConcreteHandler還需要修改。而且代碼顯然不簡單美麗。

解決方案3: 在Handler接口中只使用一個參數(shù)化方法:
public interface Handler{
  public void handleRequest(String request);
}
那么Handler實現(xiàn)代碼如下:
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);

    }
  }

}


這里先假設(shè)request是String類型,如果不是怎么辦?當(dāng)然我們可以創(chuàng)建一個專門類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實現(xiàn)代碼如下:
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, 在一個鏈上,都有相應(yīng)職責(zé)的類,因此叫Chain of Responsibility.

CoR的優(yōu)點:
因為無法預(yù)知來自外界的請求是屬于哪種類型,每個類如果碰到它不能處理的請求只要放棄就可以。無疑這降低了類之間的耦合性。

缺點是效率低,因為一個請求的完成可能要遍歷到最后才可能完成,當(dāng)然也可以用樹的概念優(yōu)化。 在Java AWT1.0中,對于鼠標(biāo)按鍵事情的處理就是使用CoR,到Java.1.1以后,就使用Observer代替CoR

擴展性差,因為在CoR中,一定要有一個統(tǒng)一的接口Handler.局限性就在這里。