使多個物件都有接受請求的機會，而只有符合自己條件的物件才能處理這個請求。
二、例項
2.1 例項：
有乙個公司x，每乙個員工都有向公司借錢的機會，但是根據數目的不同需要的審批人也不同，比如1000到5000是等級1，只需要
研發組的小組長同意就行了，但是5000到10000是等級2，需要經理同意，1萬以上就需要總經理同意了。而且每次借錢你只能向研發組
組長提出要求，然後由組長去處理。這時候就用到了責任鏈模式。
首先需要乙個類封裝人們的請求，message類就誕生了。
public class message
public void settype(int type)
public string getmessage()
public void setmessage(string message)
}
需要乙個基礎的處理類，因為不管組長還是經理，他們處理請求的邏輯都是一樣的，首先看是不是自己能處理的，能就處理，不
能就交給下乙個人。
public abstract class baserseponse
public abstract void action(message message);
public final void handler(message message) else if(this.next != null)else
}
public void setnext(baserseponse next)
}
然後完成組長、經理、總經理的角色定義
// 組長
public class response1 extends baserseponse
public response1()
@override
public void action(message message)
}//小經理
public class response2 extends baserseponse
public response2()
@override
public void action(message message)
}//大經理
public class response3 extends baserseponse
public response3()
@override
public void action(message message)
} 測試**：
response1 teamleader = new response1();
response2 smallmanager = new response2();
response3 bigmanager = new response3();
teamleader.setnext(smallmanager);
smallmanager.setnext(bigmanager);
message message1 = new message();
message1.settype(1);
message1.setmessage("等級為1的事務");
teamleader.handler(message1);
message message2 = new message();
message2.settype(2);
message2.setmessage("等級為2的事務");
teamleader.handler(message2);
message message3 = new message();
message3.settype(3);
message3.setmessage("等級為3的事務");
teamleader.handler(message3);
message message4 = new message();
message4.settype(4);
message4.setmessage("等級為4的事務");
teamleader.handler(message4);
執行結果為：
由第一責任人處理資訊：等級為1的事務
由第二責任人處理資訊：等級為2的事務
由第三責任人處理資訊：等級為3的事務
到達責任鏈末尾！
2.2 修改
你看一下測試**，是不是發現很麻煩，而且有乙個很大的問題，我可以直接將message交給小經理或者大經理，
這怎麼可以呢！所以最好還要加一層封裝，設計乙個類，我只要把請求給這個類就行了，而我不知道請求具體的提交過程。
public class submiter
public void submitmessage(message message)
}
測試**：
submiter submiter = new submiter();
submiter.submitmessage(message1);
submiter.submitmessage(message2);
submiter.submitmessage(message3);
submiter.submitmessage(message4);
執行結果沒變：
由第一責任人處理資訊：等級為1的事務
由第二責任人處理資訊：等級為2的事務
由第三責任人處理資訊：等級為3的事務
到達責任鏈末尾
三、缺點
從上面的例子中我們看到，每乙個請求的執行都需要經過很多很多的執行者，也就是說這條責任鏈很有可能會
非常的長，這樣對於程式的執行效率就不高了，所以使用的時候一定要注意。
設計模式之 責任鏈模式
在一些情況下，對乙個訊息 含事件 的響應和處理需要很多物件來參與，這些物件對訊息的處理有前後順序，形成乙個處理鏈條，但物件是否真正處理訊息有賴於在它之前的物件的處理策略，前乙個物件處理後，後乙個物件則不需參與處理，這就是責任鏈模式。現實中有很多類似的場景，比如上訪，上訪一般是從最基層的信訪部門接受信...
設計模式之（責任鏈模式）
chain of responsibleity 責任鏈模式 在責任鏈模式 中，很多物件由每乙個物件對其下家的引用而接。起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某乙個物件決定處理此請求。客戶並不知道鏈上的哪乙個物件最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者...
設計模式之責任鏈模式
假設現在乙個公司的請假流程如下 一天及以下由小組組長審批，一天以上三天以下由經理審批，三天以上七天以下由老闆審批，七天以上直接勸退。如果每次請假時都很長的if else 來判斷該去找誰請假，很不容易擴充套件，我們使用責任鏈模式來實現。首先，是乙個抽象的父類 public abstract class...