責(zé)任鏈模式(ChainofResponsibilityPattern)課件

1、第15章 責(zé)任鏈模式(Chain of Responsibility Pattern)第1頁，共43頁。行為型模式行為型模式概述 行為型模式(Behavioral Pattern)是對(duì)在不同的對(duì)象之間劃分責(zé)任和算法的抽象化。行為型模式不僅僅關(guān)注類和對(duì)象的結(jié)構(gòu)，而且重點(diǎn)關(guān)注它們之間的相互作用。通過行為型模式，可以更加清晰地劃分類與對(duì)象的職責(zé)，并研究系統(tǒng)在運(yùn)行時(shí)實(shí)例對(duì)象之間的交互。在系統(tǒng)運(yùn)行時(shí)，對(duì)象并不是孤立的，它們可以通過相互通信與協(xié)作完成某些復(fù)雜功能，一個(gè)對(duì)象在運(yùn)行時(shí)也將影響到其他對(duì)象的運(yùn)行。 第2頁，共43頁。行為型模式分為類行為型模式和對(duì)象行為型模式兩種：類行為型模式：類的行為型模式使用繼

2、承關(guān)系在幾個(gè)類之間分配行為，類行為型模式主要通過多態(tài)等方式來分配父類與子類的職責(zé)。對(duì)象行為型模式：對(duì)象的行為型模式則使用對(duì)象的聚合關(guān)聯(lián)關(guān)系來分配行為，對(duì)象行為型模式主要是通過對(duì)象關(guān)聯(lián)等方式來分配兩個(gè)或多個(gè)類的職責(zé)。根據(jù)“合成復(fù)用原則”，系統(tǒng)中要盡量使用關(guān)聯(lián)關(guān)系來取代繼承關(guān)系，因此大部分行為型設(shè)計(jì)模式都屬于對(duì)象行為型設(shè)計(jì)模式。行為型模式第3頁，共43頁。行為型模式行為型模式簡(jiǎn)介 職責(zé)鏈模式(Chain of Responsibility)命令模式(Command)解釋器模式(Interpreter)迭代器模式(Iterator)中介者模式(Mediator)備忘錄模式(Memento)觀察者模式

3、(Observer)狀態(tài)模式(State)策略模式(Strategy)模板方法模式(Template Method)訪問者模式(Visitor)第4頁，共43頁。職責(zé)鏈模式第5頁，共43頁。職責(zé)鏈模式模式動(dòng)機(jī)職責(zé)鏈可以是一條直線、一個(gè)環(huán)或者一個(gè)樹形結(jié)構(gòu)，最常見的職責(zé)鏈?zhǔn)侵本€型，即沿著一條單向的鏈來傳遞請(qǐng)求。鏈上的每一個(gè)對(duì)象都是請(qǐng)求處理者，職責(zé)鏈模式可以將請(qǐng)求的處理者組織成一條鏈，并使請(qǐng)求沿著鏈傳遞，由鏈上的處理者對(duì)請(qǐng)求進(jìn)行相應(yīng)的處理，客戶端無須關(guān)心請(qǐng)求的處理細(xì)節(jié)以及請(qǐng)求的傳遞，只需將請(qǐng)求發(fā)送到鏈上即可，將請(qǐng)求的發(fā)送者和請(qǐng)求的處理者解耦。這就是職責(zé)鏈模式的模式動(dòng)機(jī)。第6頁，共43頁。模式定義 避

4、免請(qǐng)求發(fā)送者與接收者耦合在一起，讓多個(gè)對(duì)象都有可能接收請(qǐng)求，將這些對(duì)象連接成一條鏈，并且沿著這條鏈傳遞請(qǐng)求，直到有對(duì)象處理它為止。由于英文翻譯的不同，職責(zé)鏈模式又稱為責(zé)任鏈模式，它是一種對(duì)象行為型模式。職責(zé)鏈模式第7頁，共43頁。責(zé)任鏈模式的UML類結(jié)構(gòu) 第8頁，共43頁。抽象處理者（Handler）角色 定義出一個(gè)處理請(qǐng)求的接口；如果需要，接口可以定義出一個(gè)方法，以設(shè)定和返回對(duì)下家的引用。這個(gè)角色通常由一個(gè)抽象類或接口實(shí)現(xiàn)。 具體處理者（ConcreteHandler）角色 具體處理者接到請(qǐng)求后，可以選擇將請(qǐng)求處理掉，或者將請(qǐng)求傳給下家。由于具體處理者持有對(duì)下家的引用，因此，如果需要，具體處

5、理者可以訪問下家。第9頁，共43頁。職責(zé)鏈模式模式分析在職責(zé)鏈模式里，很多對(duì)象由每一個(gè)對(duì)象對(duì)其下家的引用而連接起來形成一條鏈。請(qǐng)求在這條鏈上傳遞，直到鏈上的某一個(gè)對(duì)象處理此請(qǐng)求為止。發(fā)出這個(gè)請(qǐng)求的客戶端并不知道鏈上的哪一個(gè)對(duì)象最終處理這個(gè)請(qǐng)求，這使得系統(tǒng)可以在不影響客戶端的情況下動(dòng)態(tài)地重新組織鏈和分配責(zé)任。第10頁，共43頁。public abstractclassHandler protectedHandlersuccessor;publicvoidSetSuccessor(Handlersuccessor)this.successor=successor;abstractpublicvoi

6、dHandleRequest(intrequest);public classConcreteHandler1extendsHandlerpublicvoidHandleRequest(intrequest)if(request=0&request=10&request=20&request30) System.out.println(handledrequest: “+request.toString();elseif(successor!=null) successor.HandleRequest(request); 第12頁，共43頁。publicclassClientpublicsta

7、ticvoidmain(String args)/SetupChainofResponsibilityHandlerh1=newConcreteHandler1();Handlerh2=newConcreteHandler2();Handlerh3=newConcreteHandler3();h1.SetSuccessor(h2);h2.SetSuccessor(h3);/Generateandprocessrequestint requests=2,5,14,22,18,3,27,20;foreach(intrequestinrequests)h1.HandleRequest(request

8、);第13頁，共43頁。擊鼓傳花擊鼓者將花傳給賈母，開始傳花游戲?；ㄓ少Z母?jìng)鹘o賈赦，由賈赦傳給賈政，由賈政傳給賈寶玉，又由賈寶玉傳給賈環(huán)，由賈環(huán)傳回給賈母，如此往復(fù)。當(dāng)鼓聲停止時(shí)，手中有花的人就得執(zhí)行酒令 .第14頁，共43頁。擊鼓傳花系統(tǒng)的UML類圖第15頁，共43頁。抽象處理者 abstract class Player abstract public void handle(int i);/處理方法 private Player successor; public Player() successor = null; protected void setSuccessor(Player

9、aSuccessor) successor = aSuccessor; public void next(int index) /傳遞方法 if( successor != null ) successor.handle(index); else System.out.println(Program terminated.); 第16頁，共43頁。具體處理者class JiaMu extends Player public JiaMu(Player aSuccessor) this.setSuccessor(aSuccessor); public void handle(int i) if(

10、i = 1 ) System.out.println(Jia Mu gotta drink!); else System.out.println(Jia Mu passed!); next(i); 第17頁，共43頁?？蛻舳藀ublic class DrumBeater private static Player player; static public void main(String args) player = new JiaMu( new JiaShe( new JiaZheng( new JiaBaoYu(new JiaHuan(null); player.handle(4); 第

11、18頁，共43頁。AWT事件浮升機(jī)制事件首先傳播到它所發(fā)生的部件上，然后向其父類處理器傳播。容器可以選擇處理這個(gè)事件，或者再將此事件向更高一級(jí)的父類處理器傳播。事件如此一級(jí)級(jí)地向上傳播，就像水底的氣泡一點(diǎn)一點(diǎn)地冒到水面上一樣，因此又叫做事件浮升機(jī)制。 第19頁，共43頁。AWT庫里處理事件的代碼 public boolean action(Event event, Object obj) if (event.target = btnOK) doOKBtnAction(); else if (event.target = btnExit) doExitBtnAction(); else retu

12、rn super.action(event, obj); return true; AWT1.1的事件處理模型于1.0相比有了很大的變化。新的事件處理模型是建立在觀察者模式的基礎(chǔ)之上的，而不再是責(zé)任鏈模式的基礎(chǔ)之上的。第20頁，共43頁。AWT庫里處理事件的缺點(diǎn)AWT1.0的事件處理的模型是基于繼承的，會(huì)導(dǎo)致很多的子類，在一個(gè)面向?qū)ο蟮南到y(tǒng)里，經(jīng)常使用的應(yīng)當(dāng)是委派。由于每一個(gè)事件都會(huì)沿著部件樹結(jié)構(gòu)向上傳播，因此事件浮升機(jī)制會(huì)使得事件的處理變得較慢。第21頁，共43頁。舉例把一個(gè)對(duì)象在一個(gè)鏈接傳遞直到被處理。在這個(gè)鏈上的所有的對(duì)象有相同的接口（抽象類）但卻有不同的實(shí)現(xiàn)。java.util.log

13、ging.Logger 方法 log() Apache Tomcat 的對(duì)Encoding的處理Struts2 的攔截器jsp servlet 的FilterJavaScript事件浮升機(jī)制第22頁，共43頁。ExampleAll small children cause damage, but how should they be punished?Based upon the dollar amount of damage done by the child, the family must decide who is to punish their child.Who in this C

14、hain of Responsibility is to punish the child; The Grandma, the Mother, the Father, or something worse .muwhaahahahaaa.第23頁，共43頁。UML Diagram of Chain of responsibility第24頁，共43頁。Codeabstract class KidsPunished public int least = 15; public KidsPunished successor; public void setSuccessor(KidsPunished

15、 successor) this.successor = successor; abstract public void processRequest(PunishRequest request);第25頁，共43頁。More Codeclass Grandma extends KidsPunished public int tolerance = 10 * least; public void processRequest(PunishRequest request) if( request.getAmount() tolerance ) System.out.println(Amount

16、is $ + request.getAmount()+ , so Grandma jobs to punish); else if( successor != null) cessRequest(request); 第26頁，共43頁。Codeclass Mother extends KidsPunished private final double tolerance = 20 * least; public void processRequest(PunishRequest request) if(request.getAmount() tolerance) Sy

17、stem.out.println(Amount is $ + request.getAmount()+ , so Moms jobs to punish); else if( successor != null) cessRequest(request); 第27頁，共43頁。Codeclass Father extends KidsPunished public int tolerance = 30 * least; public void processRequest(PunishRequest request) if(request.getAmount() to

18、lerance) System.out.println(Amount is $ + request.getAmount()+ , so Fathers jobs to punish); else if(successor != null) cessRequest(request); 第28頁，共43頁。class HigherPower extends KidsPunished public int tolerance = 100 * least; public void processRequest(PunishRequest request) if(request

19、.getAmount() Director-Vice President-Presidentabstract class Approver protected final double base = 500;protected Approver successor;public void setSuccessor(Approver successor) this.successor = successor; abstract public void processRequest(PurchaseRequest request); class Manager extends Approver p

20、rivate final double ALLOWABLE = 10 * base; public void processRequest(PurchaseRequest request ) if( request.getAmount() ); double d = Double.parseDouble(new BufferedReader(new InputStreamReader(System.in).readLine(); cessRequest(new PurchaseRequest(0, d, General); catch(Exception e) Syste

21、m.exit(1); 第33頁，共43頁。純的與不純的責(zé)任鏈模式 一個(gè)純的責(zé)任鏈模式要求一個(gè)具體的處理者對(duì)象只能在兩個(gè)行為中選擇一個(gè)：一個(gè)是承擔(dān)責(zé)任，二是把責(zé)任推給下家。不允許出現(xiàn)某一個(gè)具體處理者對(duì)象在承擔(dān)了一部分責(zé)任后又把責(zé)任向下傳的情況。在一個(gè)純的責(zé)任鏈模式里面，一個(gè)請(qǐng)求必須被某一個(gè)處理者對(duì)象所接收；在一個(gè)不純的責(zé)任鏈模式里面，一個(gè)請(qǐng)求可以最終不被任何接收端對(duì)象所接收。純的責(zé)任鏈模式的例子是不容易找到的，一 般看到的例子均是不純的責(zé)任鏈模式的實(shí)現(xiàn)。第34頁，共43頁。職責(zé)鏈模式優(yōu)缺點(diǎn)職責(zé)鏈模式的優(yōu)點(diǎn) 降低耦合度 可簡(jiǎn)化對(duì)象的相互連接 增強(qiáng)給對(duì)象指派職責(zé)的靈活性 增加新的請(qǐng)求處理類很方便第3

22、5頁，共43頁。職責(zé)鏈模式的缺點(diǎn)不能保證請(qǐng)求一定被接收。系統(tǒng)性能將受到一定影響，而且在進(jìn)行代碼調(diào)試時(shí)不太方便；可能會(huì)造成循環(huán)調(diào)用。職責(zé)鏈模式優(yōu)缺點(diǎn)第36頁，共43頁。有多個(gè)對(duì)象可以處理同一個(gè)請(qǐng)求，具體哪個(gè)對(duì)象處理該請(qǐng)求由運(yùn)行時(shí)刻自動(dòng)確定。在不明確指定接收者的情況下，向多個(gè)對(duì)象中的一個(gè)提交一個(gè)請(qǐng)求?？蓜?dòng)態(tài)指定一組對(duì)象處理請(qǐng)求。應(yīng)用場(chǎng)景第37頁，共43頁。A Decorator usually wraps the decorated object: clients point to the decorator and not the objectA Decorator does not have

23、to forward the same messageA decorated object does not have to know that it is wrappedWith a chain of responsibility, the client asks the first chain objects explicitly.38Differences with Decorator第38頁，共43頁。In chain of responsibility: you can break the chain at any point Decorators can be thought of as executing all at once without any interaction with the other decoratorsLinks in a chain c