职责链模式将对象的请求处理组成链式结构,并将请求按链式结构逐个传递下去,直接被其中的某个处理者处理为止。由此可知,职责链模式的适用场合是对指定请求,可以有多个请求处理者(或称为请求响应者),但用户并不知道(也不需要知道--------此如做到请求者与响应者的解耦合)当时运行环境下该请求会被具体的哪个处理者处理(又或者说完全都没有被响应)。请求者只是抛出一个请求,响应链内部(即:模式内部)自己决定是否能处理以及谁能处理该请求。该模式的类结构图参考如下:
模式的编码结构参考如下:
1 namespace chain_of_responsibility 2 { 3 class IHandler 4 { 5 public: 6 IHandler(IHandler* pNextHandler) : m_pNextHandler(pNextHandler) {} 7 virtual ~IHandler() {} 8 virtual bool handleRequest(/*requester type parameters here........*/) { /*do something here........*/return false; } 9 10 private: 11 IHandler* m_pNextHandler; 12 13 };//class IHandler 14 15 class ConcreteHandler1 : public IHandler 16 { 17 public: 18 // some code here........ 19 virtual bool handleRequest(/*requester type parameters here........*/) { 20 /* 21 if (can handle this request) { 22 do something here........ 23 return true; 24 } else if (nullptr != m_pNextHandler) { 25 return m_pNextHandler->handleRequest(the parameters........); 26 } 27 */ 28 return false; 29 } 30 31 };//class ConcreteHandler1 32 33 class ConcreteHandler2 : public IHandler 34 { 35 public: 36 // some code here........ 37 virtual bool handleRequest(/*requester type parameters here........*/) { 38 /* 39 if (can handle this request) { 40 do something here........ 41 return true; 42 } else if (nullptr != m_pNextHandler) { 43 return m_pNextHandler->handleRequest(the parameters........); 44 } 45 */ 46 return false; 47 } 48 49 };//class ConcreteHandler2 50 51 class IRequester {}; 52 53 class Client 54 { 55 public: 56 void test() { 57 // 58 // they are test code below. 59 // 60 auto pRequester = new (std::nothrow) IRequester(); 61 auto pHandler1 = new (std::nothrow) ConcreteHandler1(nullptr); 62 auto pHandler2 = new (std::nothrow) ConcreteHandler2(pHandler1); 63 pHandler1->handleRequest(pRequester); 64 } 65 66 };//class Client 67 68 }//namespace chain_of_responsibility
职责链主要适合于对某个问题有多种解方式,并且是要在具体的环境下才能具体确定解方式。只是在设计层面上,将所有解方式链成一条链的形式,从链头到链尾逐个传递下去直到问题被某中的某个(当然也有可能都没有)解给处理掉,然后终止。即:只要有解,则解完成后传递终止,否则直至链尾。
职责链模式的好处是,将请求与请求的处理解耦合掉,使得客户不需要依赖于所有解对象,也不需要关心最终请求是被哪个解给处理,客户只关心结果。但是职责链模式在设计上,一定要注意:有些问题的解是要按具体到一般化方向链接的,否则就会出现逻辑上的问题。举例:旅游经费审批问题。
1) 当旅游经费开支 <= 1000RMB时,只需要团队的项目经理审批即可;
2) 当旅游经费开支 > 1000RMB 并且 <= 2000RMB时,需要部门主管审批才可;
3) 当旅游经费 > 2000RMB 并且 <= 3000RMB时,需要区域经理审批才可;
4) 当旅游经费高于 3000RMB时,则需要集团总裁审批。
从以上审批权限来看,项目经理的权限最低,而越往上,职位地高审批的经费额度越大。因此,假如现在开支是2345RMB,则明显的需要区域经理或更高级别的(集团总栽)审批才可以。此时问题就来了,那现在是要让集团总裁审批还是要让区域经理审批了?因为区域经理对具体的业务肯定会比集团总裁更了解,他也肯定更加清楚这笔经费的消费具体细节,理论上,是要区域经理批就可以了。而集团总栽他更注重的应该是集团公司的更大层面的问题,而不应该是这些小问题上,要不集团总栽就没有必要把审批权限开给区域经理了。所以,理论上,该笔消费应该要让区域经理来审批,只有数额大到区域经理审批不了(权限不足)时,才需要进一步上报给集团总栽,由总栽来审批。
另外,如果问题的解有非常多的情况下,其实也会给程序在调试上带来一定的影响。往往需要将所有解都要设置断点(即:断点要打很多个地方)。