Java設計形式之義務鏈形式（Chain of Responsibility形式）引見。本站提示廣大學習愛好者：（Java設計形式之義務鏈形式（Chain of Responsibility形式）引見）文章只能為提供參考，不一定能成為您想要的結果。以下是Java設計形式之義務鏈形式（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。
1.CoR的長處：由於沒法預知來自外界的要求是屬於哪一種類型，每一個類假如碰著它不克不及處置的要求只需廢棄便可以。無疑這下降了類之間的耦合性。
2.CoR的缺陷是效力低，由於一個要求的完成能夠要遍歷到最初才能夠完成，固然也能夠用樹的概念優化。 在Java AWT1.0中，關於鼠標按鍵工作的處置就是應用CoR,到Java.1.1今後，就應用Observer取代CoR。
擴大性差，由於在CoR中，必定要有一個同一的接口Handler.局限性就在這裡。
