以下内容均来自GeekBand极客班C++ 设计模式课程(李建忠老师主讲)
Composite
“数据结构”模式
常常有一些组件在内部具有特定的数据结构,如果让客户程序依赖这些特定的数据结构,将极大地破坏组件的复用。这时候,将这些特定数据结构封装在内部,在外部提供统一的接口,来实现与特定数据结构无关的访问,是一种行之有效的解决方案。
典型模式
Composite
Iterator
Chain of Resposibility
动机(Motivation)
在软件构建过程中,一个请求可能被多个对象处理,但是每个请求在运行时只能有一个接受者,如果显式指定,将必不可少地带来请求发送者与接受者的紧耦合。
如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求,从而使两者解耦。
《设计模式》GOF的定义:
使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递请求,直到有一个对象处理它为止。
其中Handler显然是稳定的,而Handler1和Handler2是变化的。
示例
现在有一个请求者:
//请求者
class Reqest{
string description;
RequestType reqType;
public:
Reqest(const string & desc,RequestType type) : description(desc),reqType(type){}
RequestType getReqType() const {return reqType;}
const string & getDescription() const {return description;}
};
现在有一些接受者,对请求进行处理:
//处理者(接收者)
class ChainHandler{
ChainHandler * nextChain;//此处为关键,一个多态的指针,指向自身,形成一个链表的结构形式
void sendReqestToNextHandler(const Reqest & req){
//如果这个链表不为空,那么请求让下一个结点继续处理
if(nextChain != nullptr){
nextChain->handle(req);
}
}
protected:
virtual bool canHandleRequest(const Reqest & req) = 0;//判断是否可以处理请求
virtual void processRequest(const Reqest & req) = 0;//具体请求的一个处理过程
public:
ChainHandler() { nextChain = nullptr;}//构造函数
void setNextChain( ChainHandler * next ) { nextChain = next; }
void handle(const Reqest & req){
if(canHandleRequest(req)){//如果这个对象能够处理,那么进行处理
processRequest(req);
}
else {//如果不能,那么给下一个指针(下一个结点)进行处理
sendReqestToNextHandler(req);
}
}
};
从Handler的内容可以看出,该类有一个指向自己的指针,形成了一个链表的形式
下面是这个类的子类:
//下面是对canHandleRequest和processRequest的具体实现部分
class Handler1 : public ChainHandler{
protected:
bool canHandleRequest(const Reqest & req){
return req.getReqType() == ............;
}
void processRequest(const Reqest & req){
cout<<"Handler1 is handle reqest:"<<req.getDescription()<<endl;
}
};
class Handler2{};
class Handler3{};
具体的实现过程如下:
int main(){
Handler1 h1;
Handler2 h2;
Handler3 h3;
h1.setNextChain(&h2);
h2.setNextChain(&h3);//形成一个链表的形式
Reqest req();
h1.handle(req);//从h1开始处理请求
return 0;
}
这就是职责链的模式,在早期(94年),职责链被认为是一种设计模式,但是今天更像是一种数据结构
要点总结
Chain of Responsibility模式的应用场合在于“一个请求可能由多个接受者,但是最后真正的接受者只有一个,这时候请求发送者与接受者的耦合有可能出现“变化脆弱”的症状,职责链的目的就是将二者解耦,从而更好地应对变化。
应用了Chain of Responsibility模式后,对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。
如果请求传递到职责链的末尾仍得不到处理,应该有一个合理的缺省机制,这也是每一个接受对象的责任,而不是发出请求对象的责任。