C++工厂方法模式在框架设计中的变体实现-源码库

C++工厂方法模式在框架设计中的变体实现：从理论到实战的深度解析

大家好，作为一名从事C++框架开发多年的工程师，今天我想和大家分享工厂方法模式在框架设计中的一些变体实现。这些经验都是我在实际项目中踩过坑、调过bug后总结出来的，希望能帮助大家在设计自己的框架时少走弯路。

为什么框架设计需要工厂方法模式

记得我第一次参与大型框架开发时，面对复杂的对象创建需求，直接使用new操作符导致代码耦合严重，维护起来苦不堪言。工厂方法模式通过将对象的创建过程封装起来，让框架的核心逻辑与具体类的实现解耦。在框架设计中，这种解耦尤为重要，因为它允许框架的使用者在不修改框架源码的情况下扩展功能。

举个实际例子，在我们开发的图形渲染框架中，需要支持多种渲染器（OpenGL、DirectX、Vulkan）。如果直接在代码中硬编码这些渲染器的创建逻辑，每次新增渲染器类型都需要修改框架核心代码，这显然违背了开闭原则。

基础工厂方法模式实现

让我们从最基础的工厂方法模式开始。假设我们有一个日志框架，需要支持文件日志和控制台日志：


class Logger {
public:
    virtual ~Logger() = default;
    virtual void log(const std::string& message) = 0;
};

class FileLogger : public Logger {
public:
    void log(const std::string& message) override {
        // 文件日志实现
    }
};

class ConsoleLogger : public Logger {
public:
    void log(const std::string& message) override {
        // 控制台日志实现
    }
};

class LoggerFactory {
public:
    virtual ~LoggerFactory() = default;
    virtual std::unique_ptr createLogger() = 0;
};

class FileLoggerFactory : public LoggerFactory {
public:
    std::unique_ptr createLogger() override {
        return std::make_unique();
    }
};

这种基础实现虽然解决了创建逻辑的封装问题，但在框架设计中往往不够灵活。我在实际使用中发现，当需要根据配置动态选择工厂时，这种设计就显得有些笨重。

参数化工厂方法变体

在实际框架开发中，我们经常需要根据运行时参数来决定创建哪种对象。这是我经过多次重构后得到的参数化工厂实现：


class AdvancedLoggerFactory {
public:
    enum class LoggerType {
        FILE,
        CONSOLE,
        NETWORK
    };
    
    std::unique_ptr createLogger(LoggerType type) {
        switch (type) {
            case LoggerType::FILE:
                return std::make_unique();
            case LoggerType::CONSOLE:
                return std::make_unique();
            case LoggerType::NETWORK:
                return std::make_unique();
            default:
                throw std::invalid_argument("Unknown logger type");
        }
    }
};

这种变体的优势在于客户端代码不需要知道具体工厂类，只需要传递一个类型参数。但要注意的是，当新增类型时仍然需要修改工厂类的代码，这在某些场景下可能不够理想。

注册式工厂方法变体

为了真正实现开闭原则，我推荐使用注册式工厂。这种实现允许在运行时动态注册新的产品类型：


class RegistryLoggerFactory {
private:
    using CreatorFunc = std::function()>;
    std::unordered_map registry_;
    
public:
    static RegistryLoggerFactory& instance() {
        static RegistryLoggerFactory instance;
        return instance;
    }
    
    void registerLogger(const std::string& type, CreatorFunc creator) {
        registry_[type] = creator;
    }
    
    std::unique_ptr createLogger(const std::string& type) {
        auto it = registry_.find(type);
        if (it == registry_.end()) {
            throw std::runtime_error("Logger type not registered: " + type);
        }
        return it->second();
    }
};

// 注册宏定义，简化使用
#define REGISTER_LOGGER(type, class) 
    static bool _registered_##class = []() { 
        RegistryLoggerFactory::instance().registerLogger(type, []() { 
            return std::make_unique(); 
        }); 
        return true; 
    }()

使用这种模式时，新增日志类型只需要在对应cpp文件中注册即可：


// 在新日志类型的实现文件中
REGISTER_LOGGER("file", FileLogger);
REGISTER_LOGGER("console", ConsoleLogger);

这种实现的妙处在于框架核心代码完全不需要知道具体有哪些日志类型，真正做到了对扩展开放、对修改关闭。

模板工厂方法变体

在性能要求极高的场景下，我通常会使用模板工厂。这种变体在编译期就确定了类型，没有任何运行时开销：


template
class TemplateLoggerFactory {
public:
    static std::unique_ptr createLogger() {
        return std::make_unique();
    }
};

// 使用示例
auto fileLogger = TemplateLoggerFactory::createLogger();
auto consoleLogger = TemplateLoggerFactory::createLogger();

虽然这种实现牺牲了一些灵活性，但在性能敏感的场景下，这种零开销抽象是非常有价值的。

实战中的注意事项和踩坑记录

在多年的框架开发中，我积累了一些宝贵的经验教训：

1. 生命周期管理
工厂创建的对象生命周期管理是关键。我强烈推荐使用智能指针，避免手动管理内存。在早期的项目中，我曾经因为忘记delete导致内存泄漏，调试了整整两天。

2. 错误处理
工厂方法应该提供清晰的错误处理机制。不要简单地返回nullptr，而是使用异常或者Expected类型来明确表达错误。

3. 配置传递
在实际框架中，创建对象通常需要配置参数。我建议使用配置对象而不是多个参数，这样在扩展时不会破坏接口：


struct LoggerConfig {
    std::string filename;
    LogLevel level;
    size_t maxSize;
};

class ConfigurableLoggerFactory {
public:
    virtual std::unique_ptr createLogger(const LoggerConfig& config) = 0;
};

性能优化技巧

在大型框架中，工厂方法的性能也很重要。以下是我总结的几个优化技巧：

对象池配合工厂
对于创建成本高的对象，可以结合对象池使用：


class PooledLoggerFactory {
private:
    std::unordered_map>> pools_;
    
public:
    std::unique_ptr createLogger(const std::string& type) {
        auto& pool = pools_[type];
        if (!pool.empty()) {
            auto logger = std::move(pool.back());
            pool.pop_back();
            return logger;
        }
        // 池中无可用对象，创建新的
        return RegistryLoggerFactory::instance().createLogger(type);
    }
    
    void returnLogger(std::unique_ptr logger) {
        // 将对象放回池中复用
    }
};