在Workflow项目中封装HTTP请求为类的实践

Workflow是一个高性能的异步编程框架，本文将探讨如何将基础的HTTP请求功能封装成类，以提高代码的可重用性和可维护性。

封装HTTP请求类的必要性

在Workflow框架中，HTTP请求通常通过创建WFHttpTask来实现。当我们需要在多个地方使用相似的HTTP请求时，直接使用原始API会导致代码重复。通过封装成类，我们可以：

1. 统一管理请求参数和配置
2. 简化调用接口
3. 便于扩展和维护
4. 提供更好的类型安全

基础封装实现

一个基础的HTTP请求类可以包含以下核心功能：

class HttpCaller {
public:
    HttpCaller() = default;

    void set_url(const std::string &url) {
        this->url = url;
    }
    
    void set_callback(std::function<void(WFHttpTask*)> callback) {
        this->callback = callback;
    }

    int execute() {
        WFHttpTask *task = WFTaskFactory::create_http_task(
            url, REDIRECT_MAX, RETRY_MAX, callback);
        
        // 配置请求参数...
        task->start();
        
        wait_group.wait();
        return 0;
    }

private:
    static const int REDIRECT_MAX = 5;
    static const int RETRY_MAX = 2;
    std::string url;
    std::function<void(WFHttpTask*)> callback;
    WFFacilities::WaitGroup wait_group{1}; // 注意初始化为1
};

关键点解析

1. WaitGroup的正确使用：WaitGroup的初始值应该设置为1，这样wait()才会等待done()被调用。初始化为0会导致立即通过。

2. 回调函数管理：使用std::function替代原始函数指针，提供更大的灵活性。

3. 请求参数封装：可以将常用的请求头、请求体等封装为类方法，简化调用。

4. 生命周期管理：确保WaitGroup的生命周期与请求周期匹配，避免资源泄漏。

改进方向

1. 支持链式调用：可以设计接口支持类似caller.set_url(...).set_method(...).execute()的链式调用。

2. 请求构建器模式：实现一个专门的请求构建器，分离请求配置和执行逻辑。

3. 结果封装：将响应结果封装为结构体或类，提供更友好的访问接口。

4. 异常处理：增强错误处理机制，提供更详细的错误信息。

实际应用示例

int main() {
    HttpCaller caller;
    caller.set_url("https://example.com/api")
         .set_method("POST")
         .set_body(R"({"key":"value"})")
         .set_header("Content-Type", "application/json");
    
    caller.set_callback([](WFHttpTask* task) {
        // 处理响应...
        wait_group.done();
    });
    
    return caller.execute();
}

通过这种封装，我们可以更专注于业务逻辑的实现，而不必每次都重复HTTP请求的配置细节。这种模式特别适合需要频繁进行HTTP通信的应用程序。