Java模式開發之責任鏈模式(上)

2019-11-18 12:16:44

字體：大中小

來源：轉載

供稿：網友

　　從擊鼓傳花談起
　　擊鼓傳花是一種熱鬧而又緊張的飲酒游戲。在酒宴上賓客依次坐定位置，由一人擊鼓，擊鼓的地方與傳花的地方是分開的，以示公正。開始擊鼓時，花束就開始依次傳遞，鼓聲一落，假如花束在某人手中，則該人就得飲酒。
　　假比說，賈母、賈赦、賈政、賈寶玉和賈環是五個參加擊鼓傳花游戲的傳花者，他們組成一個環鏈。擊鼓者將花傳給賈母，開始傳花游戲?；ㄓ少Z母傳給賈赦，由賈赦傳給賈政，由賈政傳給賈寶玉，又由賈寶玉傳給賈環，由賈環傳回給賈母，如此往復（見下圖）。當鼓聲停止時，手中有花的人就得執行酒令。
　　　 Java模式開發之責任鏈模式(上)（圖一）

　　圖1、擊鼓傳花。
　　擊鼓傳花便是責任鏈模式的應用。在責任鏈模式里，很多的對象由每一個對象對其下家的引用而聯接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重新組織鏈和分配責任。
　　責任鏈可能是一條直線、一個環鏈甚至一個樹結構的一部分。
　　責任鏈模式的結構
　　責任鏈模式是一種對象的行為模式，它所涉及到的角色如下：
　　第一、抽象處理者（Handler）角色、定義出一個處理請求的接口；假如需要，接口可以定義出一個方法，以返回對下家的引用。下圖給出了一個示意性的類圖：
　　　 Java模式開發之責任鏈模式(上)（圖二）

　　圖2、抽象處理者角色。
　　在圖中的積累關系給出了具體子類對下家的引用，抽象方法handleRequest()規范了子類處理請求的操作。
　　第二、具體處理者（ConcreteHandler）角色、處理接到請求后，可以選擇將請求處理掉，或者將請求傳給下家。下圖給出了一個示意性的類圖。
　　　 Java模式開發之責任鏈模式(上)（圖三）

　　圖3、具體處理者角色。
　　上圖中的示意性的具體處理者ConcreteHandler類只有handleRequest()一個方法。
　　責任鏈模式的靜態類結構可見下圖：
　　　 Java模式開發之責任鏈模式(上)（圖四）

　　圖4、責任鏈模式的類圖定義。
　　在圖中還給出了一個客戶端，以便讀者可以更清楚地看到責任鏈模式是怎樣應用的。抽象處理者的示意性源代碼：
　　public class Handler
　　　{
　　public void handleRequest()
　　　{
　　if (sUCcessor != null)
　　　　 {
　　　　　　 successor.handleRequest();
　　　　　 }
　　　// Write your code here
　　　 }
　　public void setSuccessor(Handler successor)
　　　 {
　　　　 this.successor = successor;
　　　 }
　　public Handler getSuccessor()
　　 {
　　　 return successor;
　　 }
　　PRivate Handler successor;
　　}　
　　代碼清單1、抽象處理者的源代碼。
　　具體處理者的示意性源代碼：
　　public class ConcreteHandler extends Handler
　　{
　　　public void handleRequest()
　　　 {
　　if (getSuccessor() != null)
　　　　 {
　　getSuccessor().handleRequest();
　　　　 }
　　　if (successor != null)
　　　　 {
　　　　　 successor.handleRequest();
　　　　 }
　　　 // Write your code here
　　　 }
　　}
　　代碼清單2、具體處理者的源代碼。
　　客戶端的源代碼如下：
　　public class Client
　　{
　　 private Handler handler;
　　 public static void main(String[] args)
　　　 {
　　　　 handler = new ConcreteHandler();
　　　　 //write your code here
　　　　}
　　}　
　　代碼清單3、客戶端的源代碼。
　　純的與不純的責任鏈模式
　　一個純的責任鏈模式要求一個具體的處理者對象只能在兩個行為中選擇一個：一是承擔責任，二是把責任推給下家。不答應出現某一個具體處理者對象在承擔了一部分責任后又把責任向下傳的情況。
　　在一個純的責任鏈模式里面，一個請求必須被某一個處理者對象所接受；在一個不純的責任鏈模式里面，一個請求可以最終不被任何接受端對象所接受。
　　純的責任鏈模式的實際例子很難找到，一般看到的例子均是不純的責任鏈模式的實現。有些人認為不純的責任鏈根本不是責任鏈模式，這也許是有道理的；但是在實際的系統里，純的責任鏈很難找到；假如堅持責任鏈不純便不是責任鏈模式，那么責任鏈模式便不會有太大的意義了。
　　java1.0版的AWT事件處理機制
　　Java的1.0版中AWT庫使用了責任鏈模式和命令模式來處理GUI的事件。由于視窗部件往往處在容器部件里面，因此當事件發生在一個部件上時，此部件的事件處理器可以處理此事件，然后決定是否將事件向上級容器部件傳播；上級容器部件接到事件后可以在此處理此事件然后決定是否將事件再次向上級容器部件傳播，如此往復，直到事件到達頂層部件。
　　事件浮升機制
　　比如，當一個視窗部件接到一個MOUSE_CLICKED事件時，事件首先傳播到它所發生的部件上，然后向其容器部件傳播。容器可以選擇處理這個事件，或者再將此事件向更高一級的容器部件傳播。事件如此一級級地向上傳播，就像水底的氣泡一點一點地冒到水面上一樣，因此又叫做事件浮升（Event Bubbling）機制。下面就是一段典型的Java1.0版的AWT庫里處理事件的代碼：
　　public boolean action(Event event, Object obj)
　　{
　　　 if (event.target == BTnOK)
　　　　 {
　　　　　 doOKBtnAction();
　　　　 }
　　else if (event.target == btnExit)
　　　　 {
　　　　　 doExitBtnAction();
　　　　 }
　　　 else
　　　　 {
　　　　　 return super.action(event, obj);
　　　　 }
　　　 return true;
　　}　
　　代碼清單4、Java1.0版本中AWT處理事件的典型代碼。
　　在這段代碼里面，action()判定目標部件是不是btnOK或btnExit；假如是，便運行相應的方法；假如不是，便返還true。一個方法返還true便使得事件停止浮升。
　　AWT1.0的事件處理的模型的缺點之一
　　AWT1.0的事件處理的模型是基于繼續的。為了使一個程序能夠捕捉GUI的事件并處理此事件，必須subclass此部件并且給其子類配備事件處理器，也就是置換掉action()方法或者handleEvent()方法。這不是應當提倡的做法：在一個面向對象的系統里，經常使用的應當是委派，繼續不應當是常態。
　　在一個復雜的GUI系統里，這樣為所有有事件的部件提供子類，會導致很多的子類，這是不是很麻煩的嗎？
　　當然，由于事件浮升機制，可以在部件的樹結構的根部部件里面處理所有的事件。但是這樣一來，就需要使用復雜的條件轉移語句在這個根部部件里辨別事件的起源和處理方法。這種非常過程化的處理方法很難維護，并且與面向對象的設計思想相違反。
　　AWT1.0的事件處理的模型的缺點之二
　　由于每一個事件都會沿著部件樹結構向上傳播，因此事件浮升機制會使得事件的處理變得較慢。這也是缺點之一。
　　比如在有些操作系統中，鼠標每移動一個色素，都會激發一個MOUSE_MOVE事件。每一個這樣的事件都會沿著部件的容器樹結構向上傳播，這會使得鼠標事件成災。
　　AWT1.0的事件處理的模型的缺點之三
　　AWT1.0的事件處理的模型只適用于AWT部件類。這是此模型的另一個缺點。
　　責任鏈模式要求鏈上所有的對象都繼續自一個共同的父類，這個類便是java.awt.Component類。
　　AWT1.0的事件處理的模型是不純的責任鏈模式
　　顯然，由于每一級的部件在接到事件時，都可以處理此事件；而不論此事件是否在這一級得到處理，事件都可以停止向上傳播或者繼續向上傳播。這是典型的不純的責任鏈模式。
　　AWT1.1以后的事件處理的模型
　　自從AWT1.1以后，AWT的事件處理模型于1.0相比有了很大的變化。新的事件處理模型是建立在觀察者模式的基礎之上的，而不再是責任鏈模式的基礎之上的。
　　關于新的事件處理模型和觀察者設計模式，請見“觀察者模式”一節。
　　紅樓夢中擊鼓傳花的故事
　　顯然，擊鼓傳花符合責任鏈模式的定義。參加游戲的人是一個個的具體處理者對象，擊鼓的人便是客戶端對象?；ù砭屏睿莻飨蛱幚碚叩恼埱?，每一個參加游戲的人在接到傳來的花時，可選擇的行為只有兩個：一是將花向下傳；一是執行酒令---喝酒。一個人不能既執行酒令，又向下家傳花；當某一個人執行了酒令之后，游戲重新開始。擊鼓的人并不知道最終是由哪一個做游戲的人執行酒令，當然執行酒令的人必然是做游戲的人們中的一個。
　　擊鼓傳花的類圖結構如下：
　　　 Java模式開發之責任鏈模式(上)（圖五）

　　圖5、擊鼓傳花系統的類圖定義。
　　單獨考慮擊鼓傳花系統，那么像賈母、賈赦、賈政、賈寶玉和賈環等傳花者均應當是“具體傳花者”的對象，而不應當是單獨的類；但是責任鏈模式往往是建立在現有系統的基礎之上的，因此鏈的結構和組成不由責任鏈模式本身決定。
　　系統的分析
　　在《紅樓夢》第七十五回里生動地描述了賈府里的一場擊鼓傳花游戲：“賈母坐下，左垂首賈赦，賈珍，賈璉，賈蓉，右垂首賈政，寶玉，賈環，賈蘭，團團圍坐。...賈母便命折一枝桂花來，命一媳婦在屏后擊鼓傳花。若花到誰手中，飲酒一杯...于是先從賈母起，次賈赦，一一接過。鼓聲兩轉，恰恰在賈政手中住了，只得飲了酒?！边@場游

上一篇：爪哇語言工廠方法創立性模式介紹(下)

下一篇：J2EE中的設計模式