C++设计模式_22_Chain of Resposibility 职责链(理解，已过时)
Chain of Resposibility 职责链也是属于“数据结构”模式。
职责链在今天整个软件框架中应用确实不多，甚至你已经在运用链表的逻辑处理程序，但是可能并不意识到它是职责链的模式，这不重要。
文章目录
- 1. 动机( Motivation )
- 2. 模式定义
- 3. Chain of Resposibility 职责链代码演示
- 4. 结构( Structure )
- 5. 要点总结
- 6. 其他参考
1. 动机( Motivation )
-
在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。
-
如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。
举例说明，在windows WPF等都会有界面的处理逻辑，顶级的是窗口，接下来有peipou，接下来是一些list，有些textbox，一层一层对象，当你鼠标点击时，事件会沿着层级链表，一层层网上传播，第一级没有处理，这个事件就往下传，这个场景就是Chain of Resposibility 职责链的一种。
2. 模式定义
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链(单向链表)，并沿着这条链传递请求，直到有一个对象处理它为止。
----《设计模式》GoF
3. Chain of Resposibility 职责链代码演示
这里是一个示意性代码，整体代码如下：
#include 代码分析：
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; }
};
上为一个 Reqest对象，负责请求等，具体的处理者或者说接收者为ChainHandler
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);
}
};
ChainHandler *nextChain;指向自身，而且作为基类存在，这是一个多态的指针，指向自身就形成了一个多态的链表，接着就是链表的处理逻辑sendReqestToNextHandler(const Reqest & req)它的逻辑是如果链表下一个节点不空，我就把我的请求交给下一个节点继续处理，canHandleRequest(const Reqest & req) = 0虚函数在运行时判断请求能不能处理，processRequest(const Reqest & req) = 0具体去处理请求。
ChainHandler() { nextChain = nullptr; }最初始化的时候链表的指针置为空指针，然后setNextChain(ChainHandler *next) { nextChain = next; }构成一个链表。
以下为整体的处理逻辑，清晰指出了职责链的处理逻辑
void handle(const Reqest & req)
{
if (canHandleRequest(req)) //做一个判断当前的对象能够处理就去处理
processRequest(req);
else
sendReqestToNextHandler(req); //如果处理不了，调用函数到下一个节点基础处理
}
基类已将主要的逻辑写好，去实现具体的一个个handler，去override基类中的两个虚函数，强调运行时来判断，这里使用了getReqType() 看看请求对象的类型是什么，是不是和所要求的匹配，比如 Handler1就是处理请求类型为RequestType::REQ_HANDLER1枚举类型的情况，相等的话就返回处理，processRequest（）是一个具体的处理逻辑。
class Handler1 : public ChainHandler{
protected:
bool canHandleRequest(const Reqest & req) override
{
return req.getReqType() == RequestType::REQ_HANDLER1;
}
void processRequest(const Reqest & req) override
{
cout << "Handler1 is handle reqest: " << req.getDescription() << endl;
}
};
一样的有Handler2、Handler3
int main(){
Handler1 h1;
Handler2 h2;
Handler3 h3;
h1.setNextChain(&h2);
h2.setNextChain(&h3);
Reqest req("process task ... ", RequestType::REQ_HANDLER3);
h1.handle(req);
return 0;
}
上面构建了3个Handler，有的时候可以在构造器里直接传递NextChain也是可以，这里是使用一个方法来实现，h1里面有一个节点指向h2，h2里面有一个节点指向h3，构成了链表。构成链表之后，Reqest req("process task ... ", RequestType::REQ_HANDLER3);中的req对象，使用枚举值告诉你将来希望哪一个对象来处理，这里是为了演示的必要性写的十分简单。在具体实现过程中，运行时判断往往没那么简单，可能是一种特定的业务逻辑。h1.handle(req);将请求对象丢给h1，先从链表的最开始，请求就会沿着链表向后传播，传递过程中遇到哪个对象能处理就处理，处理不了继续往下传递，这就是职责链的总体逻辑。
具体实现的时候很多地方会有很多灵活性，此处代码刻画的最核心的业务逻辑即“模式定义”中的“将这些对象连成一条链(单向链表)，并沿着这条链传递请求，直到有一个对象处理它为止”。
今天数据结构已经发展非常成熟，在一些人的眼里，觉得它其实不是模式，这就是数据结构的表达方式而已，在早期有些观念不是那么成熟。
4. 结构( Structure )
上图是《设计模式》GoF中定义的Chain of Resposibility 职责链的设计结构。结合上面的代码看图中最重要的是看其中稳定和变化部分，也就是下图中红框和蓝框框选的部分。
请求的发送和接收者是稳定下来的，具体底下的处理者是变化的
5. 要点总结
- Chain of Responsibility 模式的应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个”这时候请求发送者与接受煮的耦合有可能出现”变化脆弱”的症状，职责链的目的就是将二者解耦，从而好地应对变化。
”变化脆弱”上面的代码不用形成一个链表来解决，具体会把一大堆塞到一个数据结构，从头到尾去遍历，这就不太好，原因就是高度耦合。
-
应用了Chain of Responsibility 模式后，对象的
职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。 -
如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。
6. 其他参考
C++设计模式——职责链模式