職責連模式（of responsibility）：使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞請求，直到有乙個物件處理它為止。
uml圖：
* 處理者介面
*/abstract class handler
public void handlerequest(int request)
}}/*
* 處理者1
*/class concretehandler1 extends handler
public void handlerequest(int request) else
}}/*
* 處理者2
*/class concretehandler2 extends handler
public void handlerequest(int request) else
}}/*
* 處理者3
*/class concretehandler3 extends handler
public void handlerequest(int request) else }}
結果：
concretehandler1 執行handlerequest(1)
concretehandler2 執行handlerequest(13)
concretehandler1 執行handlerequest(5)
concretehandler3 執行handlerequest(28)
當客戶提交乙個請求時，請求時沿著鏈傳遞直至有乙個concretehandler物件負責處理它。接收者和傳送者都沒有對方的明確資訊，且鏈中的物件也不知道鏈的結構。結果是職責鏈可以簡化物件之間的相互鏈結，它們只需保持乙個指向其後繼的引用，而不需保持它所有候選者的引用。隨時地增加或修改處理乙個請求的結構，增強了給物件指派職責的靈活性。但需要注意的是，乙個請求極有可能到了鏈的末端都得不到處理，或者是因為沒有正確配置而得不到處理，所以要事先考慮清楚。如果不用職責鏈模式，每個處理者類的處理方法就會有很多分支，而職責鏈模式將這些判斷分支分解到了每乙個具有一定職權的具體處理類當中，然後利用事先設定的後繼者來實現處理請求的許可權問題。職責鏈模式遵循了程式設計的單一職責原則和開閉原則，這樣程式的耦合性降低，擴充套件維護也很靈活。
20 職責鏈模式
職責鏈模式 chain of responsibility 使多個物件都有機會處理請求，從而避免請求的傳送者和接收者之間的耦合關係。將這個物件連線成一條鏈，並沿著這條鏈傳遞該請求，直到有乙個 concretehandler 物件處理它為止。職責鏈模式uml結構圖 這裡發出的請求，客戶端並不知道這當中...
請求的鏈式處理 職責鏈模式（三）
為了讓採購單的審批流程更加靈活，並實現採購單的鏈式傳遞和處理，sunny公司開發人員使用職責鏈模式來實現採購單的分級審批，其基本結構如圖16 3所示 採購單 請求類 class purchaserequest public void setamount double amount public do...
請求的鏈式處理 職責鏈模式（一）
一對二 過 過 這聲音熟悉嗎？你會想到什麼？對！紙牌。在類似 鬥地主 這樣的紙牌遊戲中，某人出牌給他的下家，下家看看手中的牌，如果要不起上家的牌則將出牌請求再 給他的下家，其下家再進行判斷。乙個迴圈下來，如果其他人都要不起該牌，則最初的出牌者可以打出新的牌。在這個過程中，牌作為乙個請求沿著一條鏈在傳...