1. 职责链模式的核心概念与适用场景
职责链模式（Chain of Responsibility Pattern）是行为型设计模式中的经典成员，它通过将请求的发送者和接收者解耦，使多个对象都有机会处理这个请求。在C++中实现职责链模式时，我们通常会看到这样的结构：一个抽象处理者（Handler）定义处理请求的接口，多个具体处理者（ConcreteHandler）实现具体的处理逻辑，每个处理者持有对下一个处理者的引用。
这个模式特别适合以下场景：
- 当需要由多个对象中的一个来处理请求，但具体是哪个对象处理需要在运行时动态决定时
- 当不希望明确指定请求处理者时，比如在GUI事件处理系统中
- 当处理请求的对象集合需要动态指定时，比如中间件管道或过滤器链
提示：职责链模式与装饰器模式在结构上有些相似，但它们的意图不同。装饰器模式主要用于动态添加功能，而职责链模式关注的是请求的传递和处理。
2. 基础实现：一个简单的C++职责链示例
让我们从一个最基本的实现开始，了解职责链模式在C++中的典型结构：
cpp复制#include <iostream>
#include <string>
// 抽象处理者
class Handler {
protected:
Handler* nextHandler;
public:
Handler() : nextHandler(nullptr) {}
void setNext(Handler* handler) {
nextHandler = handler;
}
virtual void handleRequest(const std::string& request) = 0;
virtual ~Handler() {}
};
// 具体处理者A
class ConcreteHandlerA : public Handler {
public:
void handleRequest(const std::string& request) override {
if (request == "A") {
std::cout << "Handler A processing request: " << request << std::endl;
} else if (nextHandler != nullptr) {
nextHandler->handleRequest(request);
} else {
std::cout << "No handler found for request: " << request << std::endl;
}
}
};
// 具体处理者B
class ConcreteHandlerB : public Handler {
public:
void handleRequest(const std::string& request) override {
if (request == "B") {
std::cout << "Handler B processing request: " << request << std::endl;
} else if (nextHandler != nullptr) {
nextHandler->handleRequest(request);
} else {
std::cout << "No handler found for request: " << request << std::endl;
}
}
};
int main() {
Handler* handlerA = new ConcreteHandlerA();
Handler* handlerB = new ConcreteHandlerB();
handlerA->setNext(handlerB);
handlerA->handleRequest("A");
handlerA->handleRequest("B");
handlerA->handleRequest("C");
delete handlerA;
delete handlerB;
return 0;
}
这个基础实现展示了职责链模式的核心机制：每个处理者决定是否处理请求，如果不能处理就将请求传递给链中的下一个处理者。
3. 高级应用：动态职责链构建与管理
在实际项目中，职责链往往需要更灵活的构建方式。下面介绍几种高级应用技巧：
3.1 使用工厂方法创建职责链
我们可以引入工厂模式来动态创建和配置职责链：
cpp复制class HandlerFactory {
public:
static Handler* createChain(const std::vector<std::string>& handlerTypes) {
if (handlerTypes.empty()) return nullptr;
Handler* first = createHandler(handlerTypes[0]);
Handler* current = first;
for (size_t i = 1; i < handlerTypes.size(); ++i) {
Handler* next = createHandler(handlerTypes[i]);
current->setNext(next);
current = next;
}
return first;
}
private:
static Handler* createHandler(const std::string& type) {
if (type == "A") return new ConcreteHandlerA();
if (type == "B") return new ConcreteHandlerB();
// 可以扩展更多处理者类型
return nullptr;
}
};
这种方式的优势在于：
- 职责链的配置可以从外部（如配置文件）读取
- 可以动态改变处理者的顺序和组合
- 新增处理者类型时只需扩展工厂方法，不影响现有代码
3.2 使用智能指针管理职责链
在C++中，原始指针的管理容易导致内存泄漏。我们可以使用智能指针来更安全地管理职责链：
cpp复制#include <memory>
class Handler {
protected:
std::shared_ptr<Handler> nextHandler;
public:
void setNext(std::shared_ptr<Handler> handler) {
nextHandler = handler;
}
// 其他成员保持不变
};
int main() {
auto handlerA = std::make_shared<ConcreteHandlerA>();
auto handlerB = std::make_shared<ConcreteHandlerB>();
handlerA->setNext(handlerB);
handlerA->handleRequest("A");
// 不再需要手动delete，智能指针会自动管理内存
}
使用智能指针可以避免内存泄漏问题，特别是在复杂的职责链结构中。
4. 性能优化与模式变体
4.1 短路机制
在某些场景下，我们可能希望一旦某个处理者处理了请求，就不再继续传递。这可以通过修改处理逻辑实现：
cpp复制class ShortCircuitHandler : public Handler {
public:
void handleRequest(const std::string& request) override {
if (canHandle(request)) {
process(request);
return; // 短路，不再传递
}
if (nextHandler) {
nextHandler->handleRequest(request);
} else {
defaultHandling(request);
}
}
protected:
virtual bool canHandle(const std::string& request) = 0;
virtual void process(const std::string& request) = 0;
virtual void defaultHandling(const std::string& request) {
std::cout << "No handler could process: " << request << std::endl;
}
};
4.2 异步职责链
对于耗时操作，我们可以实现异步职责链：
cpp复制#include <future>
#include <vector>
class AsyncHandler : public Handler {
public:
void handleRequest(const std::string& request) override {
std::vector<std::future<void>> futures;
Handler* current = this;
while (current) {
futures.push_back(std::async(std::launch::async, [current, request] {
current->processRequest(request);
}));
current = current->nextHandler;
}
for (auto& f : futures) {
f.wait();
}
}
virtual void processRequest(const std::string& request) = 0;
};
这种变体适用于处理可以并行执行的请求，如日志记录、监控等场景。
5. 实际应用案例：HTTP请求处理管道
让我们看一个更实际的例子：实现一个简单的HTTP请求处理管道：
cpp复制#include <iostream>
#include <string>
#include <map>
class HttpRequest {
public:
std::string method;
std::string path;
std::map<std::string, std::string> headers;
std::string body;
};
class HttpResponse {
public:
int statusCode;
std::map<std::string, std::string> headers;
std::string body;
};
class HttpHandler {
protected:
HttpHandler* next;
public:
HttpHandler() : next(nullptr) {}
void setNext(HttpHandler* handler) {
next = handler;
}
virtual void handle(HttpRequest& request, HttpResponse& response) {
if (next) {
next->handle(request, response);
}
}
virtual ~HttpHandler() {}
};
class AuthenticationHandler : public HttpHandler {
public:
void handle(HttpRequest& request, HttpResponse& response) override {
if (!authenticate(request)) {
response.statusCode = 401;
response.body = "Unauthorized";
return;
}
HttpHandler::handle(request, response);
}
private:
bool authenticate(const HttpRequest& request) {
// 简化的认证逻辑
return request.headers.count("Authorization") > 0;
}
};
class RoutingHandler : public HttpHandler {
public:
void handle(HttpRequest& request, HttpResponse& response) override {
if (request.path == "/api/data") {
response.statusCode = 200;
response.body = "Data response";
return;
}
HttpHandler::handle(request, response);
}
};
class NotFoundHandler : public HttpHandler {
public:
void handle(HttpRequest& request, HttpResponse& response) override {
response.statusCode = 404;
response.body = "Not Found";
}
};
int main() {
HttpHandler* auth = new AuthenticationHandler();
HttpHandler* router = new RoutingHandler();
HttpHandler* notFound = new NotFoundHandler();
auth->setNext(router);
router->setNext(notFound);
HttpRequest request;
request.method = "GET";
request.path = "/api/data";
request.headers["Authorization"] = "Bearer token";
HttpResponse response;
auth->handle(request, response);
std::cout << "Status: " << response.statusCode << std::endl;
std::cout << "Body: " << response.body << std::endl;
delete auth;
delete router;
delete notFound;
return 0;
}
这个例子展示了如何使用职责链模式构建一个灵活的HTTP请求处理管道，每个处理者专注于单一职责（认证、路由、404处理等）。
6. 职责链模式与其他模式的结合
职责链模式可以与其他设计模式结合，产生更强大的效果：
6.1 与策略模式结合
cpp复制class ProcessingStrategy {
public:
virtual void process(const std::string& request) = 0;
virtual ~ProcessingStrategy() {}
};
class HandlerWithStrategy : public Handler {
private:
std::unique_ptr<ProcessingStrategy> strategy;
public:
explicit HandlerWithStrategy(ProcessingStrategy* s) : strategy(s) {}
void handleRequest(const std::string& request) override {
if (strategy) {
strategy->process(request);
}
if (nextHandler) {
nextHandler->handleRequest(request);
}
}
};
这种结合方式使得处理逻辑可以动态更换，提高了灵活性。
6.2 与观察者模式结合
cpp复制#include <vector>
#include <algorithm>
class ChainObserver {
public:
virtual void onRequestHandled(const std::string& request, bool handled) = 0;
virtual ~ChainObserver() {}
};
class ObservableHandler : public Handler {
private:
std::vector<ChainObserver*> observers;
public:
void addObserver(ChainObserver* observer) {
observers.push_back(observer);
}
void handleRequest(const std::string& request) override {
bool handled = tryHandle(request);
for (auto observer : observers) {
observer->onRequestHandled(request, handled);
}
if (!handled && nextHandler) {
nextHandler->handleRequest(request);
}
}
protected:
virtual bool tryHandle(const std::string& request) = 0;
};
这种结合方式允许外部对象监控职责链的处理过程，适用于日志记录、监控等场景。
7. 测试与调试职责链
测试职责链模式时，有几个关键点需要注意：
-
单元测试每个处理者：确保每个具体处理者能正确处理它能处理的请求，并能正确传递它不能处理的请求。
-
测试链条完整性：验证请求能正确通过整个链条传递，特别是在动态构建的链条中。
-
性能测试：对于长链条或处理耗时操作的链条，需要评估性能影响。
下面是一个简单的测试示例：
cpp复制#include <gtest/gtest.h>
class HandlerTest : public ::testing::Test {
protected:
void SetUp() override {
handlerA = std::make_shared<ConcreteHandlerA>();
handlerB = std::make_shared<ConcreteHandlerB>();
handlerA->setNext(handlerB);
}
std::shared_ptr<Handler> handlerA;
std::shared_ptr<Handler> handlerB;
};
TEST_F(HandlerTest, HandlesATypeRequests) {
testing::internal::CaptureStdout();
handlerA->handleRequest("A");
std::string output = testing::internal::GetCapturedStdout();
EXPECT_TRUE(output.find("Handler A processing") != std::string::npos);
}
TEST_F(HandlerTest, PassesBTypeRequests) {
testing::internal::CaptureStdout();
handlerA->handleRequest("B");
std::string output = testing::internal::GetCapturedStdout();
EXPECT_TRUE(output.find("Handler B processing") != std::string::npos);
}
TEST_F(HandlerTest, HandlesUnhandledRequests) {
testing::internal::CaptureStdout();
handlerA->handleRequest("C");
std::string output = testing::internal::GetCapturedStdout();
EXPECT_TRUE(output.find("No handler found") != std::string::npos);
}
8. 常见问题与最佳实践
在实际项目中使用职责链模式时，我总结了以下经验教训：
-
链条长度控制：过长的职责链会影响性能且难以调试。建议监控链条长度，必要时考虑其他模式。
-
避免循环引用：特别是在使用智能指针时，不小心可能创建循环引用导致内存泄漏。
-
明确的处理责任：确保每个处理者有清晰的责任范围，避免模糊不清的处理逻辑。
-
日志记录：在复杂的职责链中，添加适当的日志记录可以帮助调试。
-
考虑短路需求：明确是否需要"一旦处理就停止"的短路行为，并在设计中明确体现。
-
性能关键路径：对于性能敏感的场景，可以考虑将最可能处理的请求类型放在链条前端。
-
错误处理：设计统一的错误处理机制，避免每个处理者各自为政。
-
动态配置：考虑如何动态调整链条顺序或内容，以适应不同环境或配置。
注意：职责链模式虽然灵活，但也不是万能的。在以下情况下可能需要考虑其他模式：
- 请求总是被单一处理者处理时（考虑直接调用）
- 处理者的顺序和组合几乎不变时（可能简单函数调用更合适）
- 性能是绝对关键因素时（链条调用有一定开销）