C++责任链模式实现请求传递与处理（请求.传递.模式.责任...）

wufei123 发布于 2025-09-11 阅读（3）
责任链模式通过将请求沿处理器链传递实现解耦，适用于日志系统、审批流程等需动态处理的场景，其灵活性高但需注意未处理请求、性能开销和内存管理问题，常与命令或策略模式结合使用以提升可维护性。

c++责任链模式实现请求传递与处理

C++中的责任链模式，本质上是一种将请求的发送者和接收者解耦的设计模式。它允许我们将多个对象连接成一个链，并沿着这条链传递请求，直到有一个对象处理它。在我看来，这种模式的魅力在于它的灵活性和可扩展性，尤其是在处理具有多种处理方式或需要顺序处理的场景时，它能让我们的代码结构变得异常清晰。它不是那种“一劳永逸”的银弹，但用对了地方，它能让复杂逻辑变得井然有序。

解决方案

实现C++责任链模式，我们通常需要一个抽象的处理器基类或接口，它定义了处理请求的方法和设置下一个处理器的方法。然后，我们创建具体的处理器，它们继承或实现这个基类/接口，并实现自己的处理逻辑。如果一个处理器无法处理请求，它就将请求转发给链中的下一个处理器。

下面是一个基本的C++实现示例：

#include <iostream>
#include <string>
#include <memory> // For std::shared_ptr

// 1. 定义请求
struct Request {
    std::string type;
    std::string content;
    int priority;

    Request(std::string t, std::string c, int p) : type(std::move(t)), content(std::move(c)), priority(p) {}
};

// 2. 抽象处理器基类
class Handler {
protected:
    std::shared_ptr<Handler> nextHandler; // 使用智能指针管理下一个处理器

public:
    virtual ~Handler() = default; // 虚析构函数确保正确释放资源

    void setNext(std::shared_ptr<Handler> handler) {
        this->nextHandler = handler;
    }

    // 纯虚函数，要求子类实现具体的处理逻辑
    virtual void handleRequest(const Request& request) = 0;
};

// 3. 具体处理器A：低优先级请求处理器
class LowPriorityHandler : public Handler {
public:
    void handleRequest(const Request& request) override {
        if (request.priority <= 3) {
            std::cout << "LowPriorityHandler: 处理请求 [" << request.type << "] - " << request.content << std::endl;
        } else if (nextHandler) {
            std::cout << "LowPriorityHandler: 无法处理优先级 " << request.priority << " 的请求，转发给下一个处理器。" << std::endl;
            nextHandler->handleRequest(request);
        } else {
            std::cout << "LowPriorityHandler: 无法处理请求，且链中没有下一个处理器。" << std::endl;
        }
    }
};

// 4. 具体处理器B：中优先级请求处理器
class MediumPriorityHandler : public Handler {
public:
    void handleRequest(const Request& request) override {
        if (request.priority > 3 && request.priority <= 7) {
            std::cout << "MediumPriorityHandler: 处理请求 [" << request.type << "] - " << request.content << std::endl;
        } else if (nextHandler) {
            std::cout << "MediumPriorityHandler: 无法处理优先级 " << request.priority << " 的请求，转发给下一个处理器。" << std::endl;
            nextHandler->handleRequest(request);
        } else {
            std::cout << "MediumPriorityHandler: 无法处理请求，且链中没有下一个处理器。" << std::endl;
        }
    }
};

// 5. 具体处理器C：高优先级请求处理器
class HighPriorityHandler : public Handler {
public:
    void handleRequest(const Request& request) override {
        if (request.priority > 7) {
            std::cout << "HighPriorityHandler: 处理请求 [" << request.type << "] - " << request.content << std::endl;
        } else if (nextHandler) {
            // 理论上这里不会发生，因为高优先级是最高层，但为了完整性保留
            std::cout << "HighPriorityHandler: 无法处理优先级 " << request.priority << " 的请求，转发给下一个处理器。" << std::endl;
            nextHandler->handleRequest(request);
        } else {
            std::cout << "HighPriorityHandler: 无法处理请求，且链中没有下一个处理器。" << std::endl;
        }
    }
};

// 客户端代码
int main() {
    // 创建处理器实例
    auto lowHandler = std::make_shared<LowPriorityHandler>();
    auto mediumHandler = std::make_shared<MediumPriorityHandler>();
    auto highHandler = std::make_shared<HighPriorityHandler>();

    // 构建责任链：low -> medium -> high
    lowHandler->setNext(mediumHandler);
    mediumHandler->setNext(highHandler);

    // 发送请求
    std::cout << "--- 发送请求 ---" << std::endl;
    lowHandler->handleRequest(Request("Bug Report", "UI 崩溃问题", 2));
    lowHandler->handleRequest(Request("Feature Request", "增加暗黑模式", 6));
    lowHandler->handleRequest(Request("Urgent Fix", "生产环境数据丢失", 9));
    lowHandler->handleRequest(Request("General Query", "如何使用XXX功能", 4));
    lowHandler->handleRequest(Request("Unclassified", "未知问题", 0)); // 故意设置一个所有处理器都可能无法处理的请求，看最终结果

    return 0;
}

在这个例子中，

main
函数负责创建处理器对象并构建链。当一个请求被发送到链的头部（
lowHandler
）时，它会沿着链传递，直到被某个处理器处理，或者到达链的末尾。我个人偏爱使用
std::shared_ptr
来管理处理器之间的关系，这能有效避免内存泄漏，并且简化了生命周期管理，不用手动去
delete
。 C++责任链模式在哪些场景下能发挥最大价值？

从我多年的开发经验来看，责任链模式在那些需要解耦请求发送者和接收者，并且请求处理逻辑可能动态变化或有多个处理者选择的场景下，能发挥出它最大的价值。

一个很典型的例子是日志记录系统。设想一下，你的应用程序需要根据日志的级别（Debug, Info, Warning, Error）将日志输出到不同的地方：Debug可能只在控制台显示，Info可能写入文件，Warning可能同时写入文件和发送邮件，而Error则可能需要写入文件、发送邮件并触发告警。如果用

if-else if
结构来处理，代码会变得非常臃肿且难以维护。但如果使用责任链，你可以为每个日志级别创建一个处理器：Debug处理器、Info处理器、Warning处理器、Error处理器。当一个日志请求到来时，它会沿着链传递，每个处理器只关心它自己能处理的级别，不能处理的就传递给下一个，这让扩展新的日志输出方式变得异常简单，只需要添加一个新的处理器并将其插入到链中即可。

另一个我经常遇到的场景是审批流程。例如，一个请假申请可能需要部门经理审批、再到HR审批、最后可能还需要总经理审批，这取决于请假的天数或类型。每个审批者就是一个处理器，他们有权批准、拒绝或将请求转发给下一个审批者。这种流程天然就是线性的，责任链模式能完美契合。再比如，Web请求过滤器，一个HTTP请求在到达最终处理逻辑之前，可能需要经过认证、授权、日志记录、参数校验等一系列预处理步骤。每个步骤都可以是一个处理器，它们顺序执行，任何一个环节不通过都可以中断链条。

在我看来，这种模式的强大之处在于它的“松耦合”特性。发送者不需要知道具体哪个处理器会处理请求，甚至不需要知道有多少个处理器。它只需要将请求发送到链的头部，剩下的就交给链本身去管理。这极大地提高了系统的可维护性和可扩展性，尤其是当处理逻辑复杂且多变时，这种设计能让你的代码呼吸。

如何避免C++责任链模式中常见的陷阱和性能考量？

责任链模式虽好，但如果不加思索地滥用，也可能带来一些问题。我个人在实践中就踩过一些坑，总结下来，主要有以下几点需要注意：

PIA PIA

全面的AI聚合平台，一站式访问所有顶级AI模型

PIA226 查看详情 PIA

首先是未处理请求的问题。如果链中的所有处理器都无法处理某个请求，而链的末尾又没有一个“默认处理器”或者适当的错误处理机制，那么这个请求就会被“漏掉”，这在生产环境中是相当危险的。我的建议是，总是在链的末端设置一个通用的、能处理所有未被处理请求的“终结者”处理器，即使它只是简单地记录一个错误日志，也要确保请求不会无声无息地消失。或者，让链的最后一个处理器抛出一个异常，明确告知客户端请求未被处理。

其次是链的长度和性能。如果责任链变得非常长，那么每个请求都可能需要遍历大部分甚至整个链才能找到合适的处理器，这会引入不必要的性能开销，尤其是在高并发的系统中。在设计时，我们需要权衡链的长度和处理器的粒度。如果某些处理器总是成对出现或者处理逻辑紧密耦合，可以考虑将它们合并成一个更粗粒度的处理器。此外，如果请求的类型非常多样，可以考虑在链的早期通过某种“路由处理器”将请求分发到不同的子链，而不是让所有请求都遍历一个超长的单一链。

还有就是调试的复杂性。当链很长或者处理器逻辑复杂时，跟踪一个请求是如何被处理的，以及它在哪个环节被处理或被拒绝，可能会变得有些困难。我通常会建议在每个处理器的

handleRequest
方法中加入详细的日志输出，记录请求的进入和转发状态，这对于问题排查非常有帮助。

最后，循环引用和内存管理。如果处理器之间存在相互引用，例如

A->B
，
B->A
，且使用了原始指针，这很容易导致内存泄漏。这也是为什么我在示例代码中推荐使用
std::shared_ptr
来管理
nextHandler
。
std::shared_ptr
能很好地处理大部分情况下的所有权和生命周期问题，但如果存在循环引用，仍然需要小心，可能需要配合
std::weak_ptr
来打破循环。不过，在责任链模式中，通常是单向链表结构，循环引用的风险相对较小。但总的来说，对内存管理保持警惕总是没错的。 C++责任链模式与其他行为型模式（如命令模式、策略模式）有何异同？

在我看来，C++中的行为型设计模式，常常在解决“如何组织和管理对象的行为”这一核心问题上有所交集，但它们各自有其侧重和独特之处。责任链模式、命令模式和策略模式就是很好的例子，它们虽然都能提升代码的灵活性和可维护性，但在设计意图和应用场景上存在明显差异。

与命令模式（Command Pattern）的异同：

  • 异：
    • 目的不同： 命令模式的目的是将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。它关注的是“做什么”，并将这个“做”的行为抽象出来。而责任链模式关注的是“谁来做”，它将请求沿着一条链传递，直到找到一个合适的处理者。
    • 职责范围： 命令模式中，命令对象通常知道如何执行操作，或者知道哪个接收者来执行操作。责任链模式中，每个处理器只关心自己能否处理，如果不能，就传递给下一个，它不需要知道最终谁会处理。
    • 耦合性： 命令模式将请求的发送者和接收者完全解耦，发送者只知道命令对象，而不知道具体的接收者。责任链模式也解耦了发送者和接收者，但接收者（处理器）之间通过链条是耦合的，它们知道下一个处理器的存在。
  • 同：
    • 两者都属于行为型模式，都致力于解耦。
    • 它们可以结合使用。例如，责任链中的每个处理器在决定处理请求时，可以内部使用命令模式来执行具体的业务操作。这样，责任链负责“路由”，命令模式负责“执行”。

与策略模式（Strategy Pattern）的异同：

  • 异：
    • 目的不同： 策略模式的目的是定义一系列算法，将每一个算法封装起来，并使它们可以相互替换。它让算法的变化独立于使用算法的客户。它关注的是“如何做”，提供多种算法供选择。责任链模式关注的是“谁来做”，解决的是请求的传递和处理问题，而不是算法的选择。
    • 选择机制： 策略模式中，客户端通常需要明确选择使用哪种策略（算法）。责任链模式中，客户端将请求发送到链的头部，由链本身来决定哪个处理器来处理请求，客户端不需要知道具体的选择逻辑。
    • 处理方式： 策略模式中，通常只有一个策略会被选中并执行。责任链模式中，一个请求可能会经过多个处理器，甚至可能被多个处理器“部分”处理，或者由一个处理器完全处理后终止。
  • 同：
    • 两者都提供了灵活性和可扩展性，允许在不修改客户端代码的情况下改变行为。
    • 它们也可以结合使用。责任链中的每个处理器在处理请求时，可以根据请求的某些特性动态选择一个策略来完成具体的处理逻辑。例如，一个订单处理链中的“支付处理器”，可以根据用户的支付方式（支付宝、微信、银行卡）动态选择不同的支付策略。

总而言之，如果你需要处理一个请求，并且这个请求可能由多个对象中的一个来处理，而你又不确定具体是哪一个，那么责任链模式可能是你的首选。如果你需要将一个操作封装起来，并且支持撤销、排队等功能，那么命令模式更合适。而如果你有一系列相似但又有所不同的算法，需要根据上下文动态选择其中一个来执行，那么策略模式则能大放异彩。理解这些细微的差别，能帮助我们在实际项目中做出更明智的设计选择。

以上就是C++责任链模式实现请求传递与处理的详细内容，更多请关注知识资源分享宝库其它相关文章！

相关标签： c++ 处理器 支付宝 微信 ai ios 路由 数据丢失 为什么 red if 封装 Error 循环 指针 继承 接口 delete 并发 对象 算法 http 大家都在看： C++如何使用模板实现迭代器类 C++如何处理复合对象中的嵌套元素 C++内存模型与编译器优化理解 C++如何使用ofstream和ifstream组合操作文件 C++循环与算法优化提高程序执行效率

标签:  请求 传递 模式 

相关阅读

发表评论:

◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。

最近发表

标签列表