数据结构_ChainOfResposibility

作者出版于 design_patterns

2023-07-15 约 941 字预计阅读 2 分钟

状态变化”模式

常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件的复用。这时候，将这些特定数据结构封装在内部，在外部提供统一的接口，来实现与特定数据结构无关的访问，是一种行之有效的解决方案。典型模式

Composite
Iterator
Chain of Resposibility

1 Chain of Resposibility

1.1 模式动机

在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。

如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。

1.2 模式定义

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。

1.3 模式示例代码

# include <iostream>
# include <string>

// 抽象处理器类：请求处理器
class Handler {
public:
    virtual void setNext(Handler* next) = 0;
    virtual void handleRequest(const std::string& request) = 0;
};

// 具体处理器类：具体请求处理器
class ConcreteHandler : public Handler {
public:
    void setNext(Handler* next) {
        nextHandler = next;
    }

    void handleRequest(const std::string& request) {
        if (canHandle(request)) {
            // 处理请求
            std::cout << "处理请求：" << request << std::endl;
        } else if (nextHandler != nullptr) {
            // 传递请求给下一个处理器
            nextHandler->handleRequest(request);
        } else {
            // 无法处理请求
            std::cout << "无法处理请求：" << request << std::endl;
        }
    }

private:
    bool canHandle(const std::string& request) {
        // 根据具体情况判断是否能处理请求
        // 这里仅做示例，始终返回false
        return false;
    }

    Handler* nextHandler;
};

int main() {
    // 创建具体请求处理器
    Handler* handler1 = new ConcreteHandler();
    Handler* handler2 = new ConcreteHandler();
    Handler* handler3 = new ConcreteHandler();

    // 设置处理器的下一个处理器
    handler1->setNext(handler2);
    handler2->setNext(handler3);

    // 处理请求
    handler1->handleRequest("请求A");
    handler1->handleRequest("请求B");
    handler1->handleRequest("请求C");

    // 释放内存（可选）
    delete handler1;
    delete handler2;
    delete handler3;

    return 0;
}

2 要点总结

Chain of Responsibility 模式的应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个”，这时候请求发送者与接受者的耦合有可能出现“变化脆弱”的症状，职责链的目的就是将二者解耦，从而更好地应对变化。

应用了 Chain of Responsibility 模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。

如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。

目录