Day 3：抽象工厂模式（Abstract Factory）

抽象工厂模式（Abstract Factory）：提供一个创建一系列相关或相互依赖对象（即"产品族"）的接口，而无需指定它们的具体类。

如果说工厂方法模式解决的是"一个产品"的创建问题，那么抽象工厂解决的是"一整组配套产品"的创建问题——它把工厂方法从"一个类一个工厂"升级为"一个产品族一个工厂"。

先看一段"没有模式"的坏代码。假设我们要做一个跨平台 GUI 库，支持 Windows 和 macOS 两套风格，每套风格都有按钮和对话框两种控件。新手最常见的写法：

// 坏味道：客户端直接 new 具体类，用 if-else 手工组装"配套对象"
void buildUI(const std::string& platform) {
    std::unique_ptr<Button>  btn;
    std::unique_ptr<Dialog>  dlg;

    if (platform == "windows") {
        btn = std::make_unique<WindowsButton>();   // 平台判断散落各处
        dlg = std::make_unique<WindowsDialog>();
    } else if (platform == "mac") {
        btn = std::make_unique<MacButton>();
        dlg = std::make_unique<MacDialog>();
    } else {
        throw std::runtime_error("未知平台");
    }

    btn->render();
    dlg->show();
}

这段代码的问题非常典型：

• OCP 违背（开闭原则）：每新增一个平台（Linux、iOS），就要在所有出现 if-else 的地方各加一个分支；新增一种产品（文本框），又要在每个分支里各加一段创建代码。改一处牵动全身，改 N 处漏一处就出 bug。
• 知识泄漏 / 耦合过深：业务代码（buildUI）本不该知道"WindowsButton 存在"这件事，现在却直接依赖了所有具体类——高层模块直接依赖低层模块，违背 DIP（依赖倒置）。
• 配套关系无法保证：if-else 是"手写"的约定，没有任何机制保证"选了 Windows 就全套都是 Windows 的"。某天有人漏改一个分支，就会出现"Windows 的按钮 + Mac 的对话框"这种不伦不类的组合。
• 不可测试：想用 Mock 按钮测试业务逻辑？做不到——具体类被写死在代码里。

抽象工厂把"平台选择 + 配套对象创建"整体封装进一个工厂对象，业务代码只面向UIFactory 抽象编程，问题全部消失。

通俗解释：把"一个产品族"打包成一个整体来创建。客户端手里拿着一张"工厂卡"，这张卡要么是"Windows 全家桶卡"、要么是"macOS 全家桶卡"，刷卡时不管你要按钮还是对话框，吐出来的都是同一套风格的东西——你永远拿不到"Windows 按钮 + macOS 对话框"的混搭。

生活类比（麦当劳套餐）：点套餐时你只对服务员说"来一份 A 套餐"，而不必说"来一个香辣鸡腿堡 + 一杯中杯可乐 + 一份薯条"。A 套餐就是抽象工厂，它保证三样东西是配套组合的（都是中份、都是同一系列）；具体是哪家店做出来的（哪个具体工厂）你并不关心，反正配方统一。

生活类比（宜家样板间）：宜家的每个样板间就是一个产品族——沙发、茶几、台灯、地毯都是一个色系、一个风格的。你照着样板间整套购买（抽象工厂），绝不会出现"北欧风沙发 + 中式红木茶几"的灾难。抽象工厂就是那个"保证整屋风格统一"的样板间。

核心要点拆开看：

• 产品族（family）：位于不同产品等级结构、但属于同一系列的多个产品（WindowsButton 和 WindowsDialog 同属"Windows 族"）。
• 一致性约束由结构保证：具体工厂一次性实现所有创建方法，族内配套关系是"编译期固化"的，不是靠程序员自觉。
• 客户端只见抽象：只依赖 UIFactory、Button、Dialog 三个抽象，具体类在客户端代码中零出现。

抽象工厂有四个角色：

┌────────────────┐ 使用  ┌─────────────────┐
│    Client      │──────▶│ AbstractFactory │
│ (buildUI)      │       │ createButton()  │
└────────────────┘       │ createDialog()  │
                         └────────┬────────┘
                      implements   │   implements
              ┌────────────────────┼────────────────────┐
              ▼                    ▼                    ▼
   ┌────────────────────┐  ┌────────────────────┐
   │  WindowsFactory    │  │    MacFactory      │
   │ createButton() ────┼─▶│ createButton() ────┼──┐
   │ createDialog() ────┼─▶│ createDialog() ────┼──┤
   └────────────────────┘  └────────────────────┘  │
              │                    │                │
              ▼                    ▼                ▼
   ┌────────────────────┐  ┌────────────────────┐
   │ WindowsButton      │  │   MacButton        │  │
   │ (implements Button)│  │ (implements Button)│  │
   └────────────────────┘  └────────────────────┘  │
              │                    │                │
              ▼                    ▼                ▼
   ┌────────────────────┐  ┌────────────────────┐
   │ WindowsDialog      │  │    MacDialog       │
   │ (implements Dialog)│  │ (implements Dialog)│
   └────────────────────┘  └────────────────────┘

关键关系：客户端持有的是抽象工厂引用；每新增一个产品族（如 Linux 族），只需新增一个具体工厂 + 一组具体产品，客户端代码一行都不用改——这就是开闭原则的直接体现。

完整可编译的 C++17 示例（跨平台 UI 工厂）。所有资源用 std::unique_ptr 管理，无手工 delete、无悬空指针：

#include <iostream>
#include <memory>
#include <string>

// ========== 抽象产品 1：按钮 ==========
class Button {
public:
    virtual ~Button() = default;
    virtual void render() const = 0;
};

// ========== 抽象产品 2：对话框 ==========
class Dialog {
public:
    virtual ~Dialog() = default;
    virtual void show() const = 0;
};

// ========== 具体产品：Windows 族 ==========
class WindowsButton : public Button {
public:
    void render() const override {
        std::cout << "[Windows] 绘制直角灰色按钮\n";
    }
};

class WindowsDialog : public Dialog {
public:
    void show() const override {
        std::cout << "[Windows] 弹出直角边框对话框\n";
    }
};

// ========== 具体产品：macOS 族 ==========
class MacButton : public Button {
public:
    void render() const override {
        std::cout << "[macOS] 绘制圆角彩色按钮\n";
    }
};

class MacDialog : public Dialog {
public:
    void show() const override {
        std::cout << "[macOS] 弹出毛玻璃效果对话框\n";
    }
};

// ========== 抽象工厂：一次生产"一套"相关产品 ==========
class UIFactory {
public:
    virtual ~UIFactory() = default;
    virtual std::unique_ptr<Button> createButton() const = 0;
    virtual std::unique_ptr<Dialog> createDialog() const = 0;
};

// ========== 具体工厂：Windows 产品族 ==========
class WindowsFactory : public UIFactory {
public:
    std::unique_ptr<Button> createButton() const override {
        return std::make_unique<WindowsButton>();  // 族内配套由这里保证
    }
    std::unique_ptr<Dialog> createDialog() const override {
        return std::make_unique<WindowsDialog>();
    }
};

// ========== 具体工厂：macOS 产品族 ==========
class MacFactory : public UIFactory {
public:
    std::unique_ptr<Button> createButton() const override {
        return std::make_unique<MacButton>();
    }
    std::unique_ptr<Dialog> createDialog() const override {
        return std::make_unique<MacDialog>();
    }
};

// ========== 客户端：只依赖抽象，不认识任何具体类 ==========
void buildUI(const UIFactory& factory) {
    auto btn = factory.createButton();
    auto dlg = factory.createDialog();
    btn->render();
    dlg->show();
}

int main() {
    std::cout << "=== 在 Windows 平台构建界面 ===\n";
    WindowsFactory winFactory;
    buildUI(winFactory);          // 传入哪个工厂，就是哪套风格

    std::cout << "\n=== 在 macOS 平台构建界面 ===\n";
    MacFactory macFactory;
    buildUI(macFactory);
    return 0;
}

程序输出：

=== 在 Windows 平台构建界面 ===
[Windows] 绘制直角灰色按钮
[Windows] 弹出直角边框对话框

=== 在 macOS 平台构建界面 ===
[macOS] 绘制圆角彩色按钮
[macOS] 弹出毛玻璃效果对话框

注意：buildUI 的函数签名里只有 UIFactory、Button、Dialog 三个抽象类型——把 main 里的工厂换成 LinuxFactory，整个业务代码零改动即可切换到 Linux 风格。这就是抽象工厂与直接 new 的本质区别。

我们实现一个主题化样式工厂：深色/浅色两套"产品族"，每套包含按钮风格与面板风格两个"产品"。UI 代码只面对 ThemeFactory 抽象，切换主题就是切换工厂。

ThemeFactory.h（完整头文件）

#ifndef THEMEFACTORY_H
#define THEMEFACTORY_H

#include <QString>
#include <memory>

// 抽象产品 1：按钮风格
class ButtonStyle {
public:
    virtual ~ButtonStyle() = default;
    virtual QString background() const = 0;   // 背景色
    virtual QString foreground() const = 0;   // 文字色
};

// 抽象产品 2：面板风格
class PanelStyle {
public:
    virtual ~PanelStyle() = default;
    virtual QString background() const = 0;   // 背景色
    virtual QString border() const = 0;       // 边框色
};

// 抽象工厂：一个工厂生产"一套"互相匹配的风格对象
class ThemeFactory {
public:
    virtual ~ThemeFactory() = default;
    virtual std::unique_ptr<ButtonStyle> makeButtonStyle() const = 0;
    virtual std::unique_ptr<PanelStyle>  makePanelStyle()  const = 0;
};

#endif // THEMEFACTORY_H

ThemeFactory.cpp（实现 + 简单工厂入口）

#include "ThemeFactory.h"

// ---------- 深色主题产品族 ----------
class DarkButtonStyle : public ButtonStyle {
public:
    QString background() const override { return QStringLiteral("#2b2b2b"); }
    QString foreground() const override { return QStringLiteral("#ffffff"); }
};

class DarkPanelStyle : public PanelStyle {
public:
    QString background() const override { return QStringLiteral("#1e1e1e"); }
    QString border()       const override { return QStringLiteral("#444444"); }
};

class DarkThemeFactory : public ThemeFactory {
public:
    std::unique_ptr<ButtonStyle> makeButtonStyle() const override {
        return std::make_unique<DarkButtonStyle>();
    }
    std::unique_ptr<PanelStyle> makePanelStyle() const override {
        return std::make_unique<DarkPanelStyle>();
    }
};

// ---------- 浅色主题产品族 ----------
class LightButtonStyle : public ButtonStyle {
public:
    QString background() const override { return QStringLiteral("#f5f5f5"); }
    QString foreground() const override { return QStringLiteral("#111111"); }
};

class LightPanelStyle : public PanelStyle {
public:
    QString background() const override { return QStringLiteral("#ffffff"); }
    QString border()       const override { return QStringLiteral("#cccccc"); }
};

class LightThemeFactory : public ThemeFactory {
public:
    std::unique_ptr<ButtonStyle> makeButtonStyle() const override {
        return std::make_unique<LightButtonStyle>();
    }
    std::unique_ptr<PanelStyle> makePanelStyle() const override {
        return std::make_unique<LightPanelStyle>();
    }
};

// 工厂选择入口：按名字返回对应产品族工厂（用 unique_ptr 明确所有权）
std::unique_ptr<ThemeFactory> createThemeFactory(const QString& name) {
    if (name == QStringLiteral("dark")) {
        return std::make_unique<DarkThemeFactory>();
    }
    return std::make_unique<LightThemeFactory>();
}

main.cpp

#include <QCoreApplication>
#include <QDebug>
#include "ThemeFactory.h"

// 客户端只依赖抽象工厂与抽象产品，主题切换零改动
static void applyTheme(const ThemeFactory& factory) {
    auto button = factory.makeButtonStyle();
    auto panel  = factory.makePanelStyle();
    qInfo().noquote() << "按钮背景:" << button->background()
                      << "文字颜色:" << button->foreground();
    qInfo().noquote() << "面板背景:" << panel->background()
                      << "边框颜色:" << panel->border();
}

int main(int argc, char *argv[]) {
    QCoreApplication app(argc, argv);

    qInfo() << "=== 深色主题 ===";
    auto dark = createThemeFactory(QStringLiteral("dark"));
    applyTheme(*dark);

    qInfo() << "=== 浅色主题 ===";
    auto light = createThemeFactory(QStringLiteral("light"));
    applyTheme(*light);

    return 0;
}

CMakeLists.txt

cmake_minimum_required(VERSION 3.16)
project(ThemeFactoryDemo VERSION 1.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_AUTOMOC ON)

find_package(Qt6 REQUIRED COMPONENTS Core)

add_executable(theme_factory_demo
    main.cpp
    ThemeFactory.cpp
    ThemeFactory.h
)

target_link_libraries(theme_factory_demo PRIVATE Qt6::Core)

程序输出：

=== 深色主题 ===
按钮背景: "#2b2b2b" 文字颜色: "#ffffff"
面板背景: "#1e1e1e" 边框颜色: "#444444"
=== 浅色主题 ===
按钮背景: "#f5f5f5" 文字颜色: "#111111"
面板背景: "#ffffff" 边框颜色: "#cccccc"

以最小 C++ 示例为例，程序执行过程分四步：

1. 选择工厂：main 创建 WindowsFactory（或在 Qt 例中通过 createThemeFactory("dark") 拿到深色工厂）。此时客户端手里只有抽象引用 const UIFactory&，多态绑定到具体工厂。
2. 按需创建产品：buildUI 依次调用 factory.createButton()、factory.createDialog()。虚函数分派到 WindowsFactory 的实现，用 make_unique 在堆上构造具体产品，返回 unique_ptr<Button> / unique_ptr<Dialog>（向上转型为抽象产品）。
3. 业务使用：客户端通过抽象接口调用 render() / show()，运行时多态输出 Windows 风格文本。整个过程中客户端从未出现 WindowsButton 字样，也从不负责释放内存——RAII 的 unique_ptr 在离开作用域时自动回收。
4. 切换产品族：main 换用 MacFactory，重复步骤 2-3，输出整套 macOS 风格；配套一致性由具体工厂的固定实现保证，不存在"混搭"可能。

Qt 示例的执行流程完全相同，只是入口换成了 createThemeFactory(name) 这个"工厂选择器"（它本身是一个简单工厂/工厂方法，返回的却是抽象工厂——两层工厂协作是工程中的常见组合）。

抽象工厂的设计目标，是把"创建逻辑"与"使用逻辑"彻底分离，并让一致性约束从"程序员的自觉"变成"结构上的必然"：

• 解耦点：客户端 ↔ 具体产品。客户端只认识 UIFactory/Button/Dialog 三个抽象，具体类只出现在工厂内部。改产品实现、换产品族，客户端零感知。
• OCP（开闭原则）：新增产品族 = 新增一个具体工厂 + 一组具体产品，不改动任何已有代码；新增产品类型（如文本框）需要给所有工厂加方法，属于"扩展点"设计，但产品族扩展的频率远低于产品类型扩展——这正是抽象工厂的适用前提。
• DIP（依赖倒置）：高层业务模块依赖抽象工厂与抽象产品，不再依赖任何具体类；具体工厂反过来实现抽象接口，依赖关系全部指向抽象层。
• 组合优于继承：工厂之间是平级组合关系而非继承链，产品族切换本质上是"替换一个组件"，符合"组合优于继承"的指导思想。
• 可测试性：测试中传入 MockFactory（返回假按钮、假对话框），业务逻辑即可在无 UI 环境下单测；生产环境换真实工厂，测试代码零修改。
• 一致性由构造保证：具体工厂把整套创建方法写在一个类里，从根源上杜绝"不同系列产品混搭"。

回到第②节的坏代码，想象系统持续演进会发生什么：

• if-else 膨胀：平台从 2 个涨到 5 个（Windows/macOS/Linux/iOS/Android），产品从 2 种涨到 6 种（按钮/对话框/菜单/滚动条/输入框/标签）。每个"创建点"要写 5×6=30 个分支，而创建点散布在十几个业务函数里——总计数百个分支，改一个平台名要全局搜索替换，漏一个就出"混搭 bug"。
• 耦合爆炸：业务层直接 new 具体类，意味着业务模块依赖全部具体产品类。任何产品的构造函数签名变化（如 WindowsButton(int style)），所有调用点全部编译失败，牵一发动全身。
• 一致性失控：没有结构约束，"Windows 按钮 + Mac 对话框"的组合随时可能出现；这类 bug 不会编译报错、不会崩溃，只在用户界面上表现为"风格不统一"，极难定位。
• 测试瘫痪：业务代码写死具体类，无法注入 Mock；想测试"切换平台后界面逻辑"必须真的跑在对应平台上。
• 类爆炸（反面教材的另一面）：有人为了消灭 if-else 给每种产品单独建工厂（工厂方法过度使用），结果工厂类比产品类还多，管理成本反而上升——这正是抽象工厂存在的意义：一个工厂管一组产品，工厂数量 = 产品族数量。

适合使用的场景（3-5 个）：

• 系统需要支持多个产品族，且同一族内的产品必须配套使用（跨平台 UI 控件、主题皮肤、数据库驱动、通讯协议族）。
• 系统将来可能增加新的产品族，且希望新增时不影响既有代码（OCP 扩展点明确）。
• 产品族的一致性约束是硬性需求，需要用结构而非约定来保证（如"选深色主题则所有控件都深色"）。
• 你想隐藏产品创建细节，让客户端只面对抽象接口编程，同时方便测试注入 Mock 工厂。
• Qt 中做可切换主题/平台风格的应用（QSS 主题包、自定义 style 插件）——每个主题就是一个产品族。

不适合使用的场景（2-4 个）：

• 系统只有一个产品族、或产品之间没有配套关系——工厂方法模式就够用，抽象工厂是"杀鸡用牛刀"。
• 产品类型频繁新增（每加一种产品就要改所有具体工厂，违反 OCP）——此时应优先考虑注册表 + 工厂方法，或干脆用直接构造。
• 创建逻辑极简单（如只有一个构造函数调用），引入工厂层反而增加间接性，不值得。
• 产品对象生命周期简单、无族约束、调用方也需要具体类型信息——直接 new 更清晰。

Qt 是抽象工厂的"重度用户"，最典型的三个实例：

• QPlatformTheme（QPA 平台抽象层）：这是抽象工厂的教科书实现。每个平台插件（Windows/macOS/XCB 等）提供一个 QPlatformTheme 子类，通过 createDialog(QPlatformDialogHelper::Type)、createMenuBar()、createSystemTrayIcon() 等一整套方法，生产该平台"配套"的原生 UI 组件。业务代码只面对 QPlatformTheme 抽象——这就是为什么同样的 QFileDialog 在 Windows 上是原生对话框、在 Linux 上是自绘对话框，而应用代码一行不用改。
• QStyleFactory + QStyle：QStyleFactory::create(name) 是工厂方法，但各平台 QStyle 子类（Fusion、Windows、macOS 风格）各自负责"一整套控件"的绘制（按钮、滚动条、菜单……所有控件），从"产品族"角度理解：一种风格 = 一个产品族，风格切换 = 工厂切换。
• Qt Quick Controls 2 的 Style：Material / Fusion / Imagine / Universal 四种 Style 各自提供完整的控件主题族，应用通过 QT_QUICK_CONTROLS_STYLE 环境变量或 QQuickStyle 切换——底层正是"主题族工厂"的思想。

此外 QSqlDatabase 的驱动层（QSQLITE/QMYSQL/QPSQL）可理解为"注册表 + 工厂方法"风格的变体，它是按单个驱动创建，属于工厂方法而非严格抽象工厂。在 Qt 里写插件（QPluginLoader）时，一个插件暴露的 QObject 通常也承担"抽象工厂"角色：通过一个入口对象创建该插件的整套服务。