设计原则在配置系统中的应用：配置文件的解析与验证，策略模式实现配置热加载

配置系统，说白了就是软件的“开关面板”。

我做了十几年C++开发，见过太多因为配置管理混乱导致的线上事故。有的团队把配置写死在代码里，改个数据库连接池大小都要重新编译上线；有的虽然用了配置文件，但解析和验证逻辑散落在各个模块里，改一处漏三处。

嗯，今天我们就来聊聊，怎么用设计原则把配置系统做得既健壮又灵活。

配置文件的解析与验证：单一职责原则的典型应用

先看一个最常见的场景：你的程序启动时需要读取一个JSON或YAML配置文件。

很多新手会这么写：

class Config {
public:
    void load(const std::string& path) {
        // 打开文件
        std::ifstream file(path);
        // 解析JSON
        nlohmann::json j;
        file >> j;
        // 验证字段
        if (!j.contains("server_port")) throw std::runtime_error("missing port");
        port_ = j["server_port"];
        // 验证类型
        if (!j["server_port"].is_number()) throw std::runtime_error("port must be number");
        // ... 还有几十个字段要处理
    }
private:
    int port_;
    std::string host_;
    // ... 几十个成员变量
};

这段代码有什么问题？

我告诉你，它把三件事揉在了一起：文件读取、格式解析、业务验证。哪天你想从JSON换成YAML，或者想增加一个“端口范围校验”，就得改这个类。改着改着，这个类就变成了一个几百行的“大泥球”。

我建议这样拆分：

// 职责1：文件读取
class FileReader {
public:
    std::string read(const std::string& path);
};

// 职责2：格式解析
class JsonParser {
public:
    nlohmann::json parse(const std::string& content);
};

// 职责3：业务验证
class ConfigValidator {
public:
    void validate(const nlohmann::json& j);
};

// 最终组装
class ConfigLoader {
public:
    Config load(const std::string& path) {
        auto content = reader_.read(path);
        auto json = parser_.parse(content);
        validator_.validate(json);
        return Config::fromJson(json);
    }
private:
    FileReader reader_;
    JsonParser parser_;
    ConfigValidator validator_;
};

你看，每个类都只做一件事。想换解析格式？换掉JsonParser就行。想增加验证规则？改ConfigValidator。互不影响。

策略模式实现配置热加载

配置文件解析完了，程序跑起来了。但问题来了——线上运行的服务，有时候需要动态调整参数，比如日志级别、限流阈值。总不能每次都重启服务吧？

这时候就需要配置热加载。

热加载的核心思路很简单：程序定期检查配置文件是否变更，如果变了就重新加载。但这里有个设计难点——不同的配置项，变更后的处理方式完全不同。

• 日志级别变了：只需要改一个全局变量
• 数据库连接池大小变了：需要重建连接池
• 路由规则变了：需要重新编译路由表
• 黑白名单变了：需要更新内存中的集合

如果把这些逻辑都写在同一个onConfigChanged()函数里，用一堆if-else来判断，那代码很快就会变成一团乱麻。

策略模式正好解决这个问题。

// 策略接口
class ConfigChangeHandler {
public:
    virtual ~ConfigChangeHandler() = default;
    virtual void handle(const nlohmann::json& oldConfig, 
                        const nlohmann::json& newConfig) = 0;
};

// 具体策略1：日志级别变更
class LogLevelHandler : public ConfigChangeHandler {
public:
    void handle(const nlohmann::json& oldConfig, 
                const nlohmann::json& newConfig) override {
        if (oldConfig["log_level"] != newConfig["log_level"]) {
            Logger::setLevel(newConfig["log_level"]);
            std::cout << "日志级别已更新" << std::endl;
        }
    }
};

// 具体策略2：连接池变更
class ConnectionPoolHandler : public ConfigChangeHandler {
public:
    void handle(const nlohmann::json& oldConfig, 
                const nlohmann::json& newConfig) override {
        if (oldConfig["pool_size"] != newConfig["pool_size"]) {
            ConnectionPool::resize(newConfig["pool_size"]);
            std::cout << "连接池大小已调整" << std::endl;
        }
    }
};

// 热加载管理器
class HotReloadManager {
public:
    void registerHandler(const std::string& key, 
                         std::unique_ptr<ConfigChangeHandler> handler) {
        handlers_[key] = std::move(handler);
    }

    void reload(const nlohmann::json& oldConfig, 
                const nlohmann::json& newConfig) {
        for (auto& [key, handler] : handlers_) {
            handler->handle(oldConfig, newConfig);
        }
    }
private:
    std::unordered_map<std::string, 
                       std::unique_ptr<ConfigChangeHandler>> handlers_;
};

这样设计的好处是什么？

• 新增一种配置变更处理，只需要写一个新的Handler类，注册进去就行
• 每个Handler只关心自己负责的那部分配置，不需要知道其他配置的存在
• 测试的时候可以单独测试每个Handler，不用启动整个系统

整体架构图

下面这张图展示了配置系统的整体流程：

总结一下关键点

配置系统看似简单，但要做好其实不容易。我总结了几条经验：

1. 解析和验证要分离——解析只负责格式正确，验证负责业务正确。这样改解析库不影响验证逻辑。
2. 热加载用策略模式——每种配置变更的处理方式独立成一个策略类，互不干扰。
3. 版本控制不能忘——热加载时一定要检查配置版本，防止旧配置覆盖新配置。
4. 变更要有回滚能力——我习惯在Handler里保存旧值，如果新配置导致异常，能自动回滚到上一个稳定版本。

嗯，配置系统的设计就聊到这里。记住一句话：好的配置系统，应该是“改了配置就像改了个变量一样简单”。