职责链_0.docVIP

职责链 篇一：职责链 今天来进行其他两个模式的对决，1号选手职责链模式，2号选手状态模式。开始对决：职责链模式VS状态模式。首先来看看1号选手职责链模式的简介，它的定义为：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一对象处理它为止。它的UML图如下：下面来看看1号选手职责链模式的好处：当客户提交一个请求时，请求是沿链传递直至有一个ConcreteHander对象负责处理它。接收者和发送者都没有对方的明确信息，且链中的对象自己并不知道链的结构。结果是职责链可简化对象的相互连接，它们仅需保持一个指向其后继者的引用或指针，而不需要保持它所有的候选接受者。这也就大大降低了耦合度了。也就是说，我们可以随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。不过在设计职责链时要当心，如果一个请求到了链的末端都得不到处理，或者因为没有正确配置而得不到处理，就很糟糕了。同时由于职责链模式是把请求没链传递直到有一个ConcreteHander对象可以处理它，那么就可以消除程序中的大量的if...else...语句，以下是本人写的一个小例子：#include iostream using namespace std;class Handlepublic:void SetSuperior(Handle *p)pHle = p;virtual void HandleRequest(int key)=0;virtual ~Handle(){}protected:Handle(){}Handle *pHle;class HandleA:public Handlenbsp; nbsp; //只能处理key 0的情况的能力public:virtual void HandleRequest(int key)if(key 0)cout the Request has Handle by HandleA key = key endl;pHle- HandleRequest(key);class HandleB:public Handlenbsp; nbsp; //只能处理key为0～2的情况public:virtual void HandleRequest(int key)if(key = 0 key 2)cout the Request has Handle by HandleB key = key endl;pHle- HandleRequest(key);class HandleC:public Handle nbsp;//可以处理所有的请求public:virtual void HandleRequest(int key)cout the Request has Handle by HandleC key = key endl;int main()Handle *ha(new HandleA);Handle *hb(new HandleB);Handle *hc(new HandleC);ha- SetSuperior(hb);hb- SetSuperior(hc);const int nmaxsize(5);int nRequest[nmaxsize]={-1,-2,0,1,2};for(int i = 0; i nmaxsize; i)ha- HandleRequest(nRequest[i]);delete ha;delete hb;delete hc;system( pause return 0;由此可见，若不使用职责链模式，而把处理的代码写成一个类，则需要大量的if...else...来判断传入的参数的 （x 0,0 =x 2,x =2），而且不易于维护，复用和扩展，一旦有新的请求就要修改类的代码，使类的结构变得复杂，也违反了开放-封闭原则。用职责链模式，则只需要为新的功能写成一个继承于Hande的子类并SetSuperor即可。好了，看了1号选手介绍这么多，以下来看看2号选手状态模式的介绍。首先看看它的定义：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变其类。以下是它的UML图：下面看看2号选手状态模式的好处和用处：1、状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。2、状态模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。即将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在于某个ConcreteState中，所以通过定义新的子类可以很容易地增加新的状态和转换。这样做的目的是为了消除庞大的条件