Day 20：策略模式（Strategy Pattern）

策略模式（Strategy Pattern）：定义一族算法（或业务规则），将每一个算法分别封装成独立的对象并使它们实现同一个抽象接口，从而让它们可以在运行时互相替换——算法的变化独立于使用算法的客户端。它属于 GoF 23 种设计模式中的行为型模式，别名 Policy（政策/策略）。

一句话记忆：「把会变的算法装进可替换的盒子里，上下文只认接口、不认实现。」

今天是我们行为型模式之旅的第二站。上一站（Day 19）的状态模式关注「对象内部状态变化时行为如何自动切换」，今天的策略模式则关注「同一件事有多种做法时，如何让做法本身可以被自由插拔」。两者代码结构极其相似，但意图截然不同，第 ⑪ 节会专门辨析。

先看一段没有策略模式、但几乎所有真实项目里都出现过的「坏代码」。假设电商系统要按用户类型计算订单折后价：

// 坏味道示例：类型枚举 + 集中式 switch 分支
enum class UserType { Normal, Student, Vip, Enterprise };

// 价格计算：随着用户类型和促销活动增多，这个函数会越来越臃肿
double calcFinalPrice(double price, UserType type, bool withCoupon) {
    double p = price;
    switch (type) {
    case UserType::Normal:              break;               // 无折扣
    case UserType::Student:   p *= 0.85; break;              // 学生 85 折
    case UserType::Vip:       p *= 0.70; break;              // VIP 7 折
    case UserType::Enterprise:p *= 0.90; break;              // 企业 9 折
    }
    if (withCoupon && p >= 200.0) p -= 50.0;   // 满 200 减 50 的优惠券
    return p;
}

这段代码在功能上是正确的，但随着业务演进，问题会集中爆发：

• if-else / switch 膨胀：明天加一个「PLUS 会员 8 折」，后天加「618 全场 9 折」「双 11 满 300 减 80」……每一个新规则都要回到这个函数里再插一个分支，函数越来越长，可读性越来越差。
• 分支逻辑被复制粘贴到各处：不仅算价格要按 UserType 分支，算积分（student ×1.5 倍积分）、算运费（VIP/企业包邮）、渲染会员标签时都要复制同一份类型判断。某天把学生折扣从 85 折改成 79 折，漏改其中一个复制点，就是一笔线上事故。
• 组合爆炸：真实规则往往是叠加的——「VIP + 优惠券 + 618 活动」怎么算？if-else 只能线性叠加，规则一多，条件组合呈指数级增长，穷举测试根本写不完。
• 无法独立测试：想单独验证「学生折扣算法」必须构造一个完整的 calcFinalPrice 调用，还要带上其他不相关的参数，测试用例互相纠缠。

从 SOLID 原则角度审视这段坏代码：

• 违背开闭原则（OCP）：新增一种计价规则，必须修改 calcFinalPrice 这个已经稳定的核心函数——对扩展不开放，对修改不关闭。
• 违背单一职责原则（SRP）：一个函数同时承担了「订单金额计算流程」和「N 种互不相关的计价算法」两类职责，任何一个算法的变化都会波及整体。
• 违背依赖倒置原则（DIP）：调用方直接依赖具体枚举值和内联算法细节，而不是依赖稳定的抽象；策略细节的改动向上传导到所有调用点。

策略模式的本质只有三句话：

1. 为一系列算法定义一个统一的抽象接口（Strategy）；
2. 每个算法写成一个独立的类（ConcreteStrategy），各自实现该接口；
3. 使用算法的上下文（Context）不再自己写算法，而是持有一个策略接口的引用，把计算请求委托给当前持有的策略对象——想换算法？换掉这个引用即可。

通俗地讲：Context 是「老板」，策略是「员工」。老板不亲自干活，他只认「能干这活的员工」这个身份（接口），具体派哪个员工上，随时可以换。老板的日常工作流程（接单、验收、交付）完全不受换人影响。

生活类比 1 —— 手机地图导航：你的目的地（Context 的业务目标）是固定的，但「驾车」「公交」「骑行」「步行」是四种不同的路线算法（策略）。地图 App 的框架不会因为你切换出行方式而重写，它只是把你选择的交通方式对应的算法插进去，然后调用「计算路线」这个统一入口。App 与具体算法互不干扰，算法之间也互不知晓。

生活类比 2 —— 商场收银台：收银流程（扫商品 → 报价 → 收款 → 出小票）是固定的；但「现金」「银行卡」「扫码支付」「数字人民币」是四种支付算法。收银员不需要知道每种支付的内部规则，只要顾客说「扫码」，就调用扫码策略。未来新增一种支付方式，收银台和收银机程序一行都不用改，只需要「注册」一个新的支付策略。

这两个类比揭示了策略模式的灵魂：把「做什么」（稳定的业务骨架）与「怎么做」（易变的算法细节）分离，变化的部分通过接口插拔，稳定部分永不触碰变化部分。

策略模式的结构图非常简洁，只有三个角色 + 一个客户端：

                    ┌──────────────────────┐
                    │      Context         │  （上下文：如 Checkout 结算器）
                    │ ┌──────────────────┐ │
             委托 ──▶│ │  m_strategy: 接口*│ │  持有策略的引用/指针
                    │ └──────────────────┘ │
                    └──────────┬───────────┘
                               │ 调用统一接口
                    ┌──────────▼───────────┐
                    │   «interface»        │
                    │   Strategy           │  （抽象策略）
                    │   +algorithm()       │
                    └──────────┬───────────┘
             ┌─────────────────┼─────────────────┐
     ┌───────▼───────┐ ┌───────▼───────┐ ┌───────▼───────┐
     │ ConcreteA     │ │ ConcreteB     │ │ ConcreteC     │  （具体策略）
     │ +algorithm()  │ │ +algorithm()  │ │ +algorithm()  │
     └───────────────┘ └───────────────┘ └───────────────┘
                ▲
                │ 实例化（由客户端/工厂创建后注入 Context）

角色	名字	职责	变化维度
抽象策略	Strategy	定义算法族统一的公共接口（通常只有一个核心方法，如 calc/render/sort）	稳定，几乎不变
具体策略	ConcreteStrategyA/B/C…	各自实现一种算法/规则，互不感知、互不依赖	易变：新增算法 = 新增一个类
上下文	Context	持有 Strategy 引用；把业务请求转发（委托）给策略；不关心具体是哪个策略	稳定：算法更换不影响它
客户端	Client	创建具体策略对象并注入 Context（构造注入或 set 注入），决定「当前用哪个策略」	只与抽象策略打交道

协作时序：① 客户端实例化一个具体策略；② 把它注入 Context（构造函数或 setStrategy）；③ 客户端调用 Context 的业务方法；④ Context 把请求转发给持有的策略对象；⑤ 策略对象执行自己的算法并返回结果；⑥ 需要换算法时，客户端再注入另一个策略对象，Context 内部代码零改动。

注意两个实现细节：其一，Context 与 Strategy 是组合（聚合）关系而非继承关系——这是「组合优于继承」的典型体现；其二，策略对象可以是无状态的（只有算法没有数据成员），此时可以做成共享单例供多个 Context 复用，进一步节省内存。

以第 ② 节的电商折扣为例，用策略模式重构。核心变化：UserType 枚举 + switch 消失，代之以一个抽象接口和四个策略类；结算器 Checkout（Context）持有一个 std::unique_ptr 策略指针，运行时可更换。完整可编译，无需任何第三方库：

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

// ========== 抽象策略：所有「优惠算法」的统一接口 ==========
class IDiscountStrategy {
public:
    virtual ~IDiscountStrategy() = default;   // 基类必须虚析构
    virtual double calc(double price) const = 0;  // 输入原价，返回应付价
    virtual std::string name() const = 0;         // 策略名（演示/日志用）
};

// ========== 具体策略 A：普通用户，无折扣 ==========
class NormalDiscount final : public IDiscountStrategy {
public:
    double calc(double price) const override { return price; }
    std::string name() const override { return "普通用户(无折扣)"; }
};

// ========== 具体策略 B：学生 85 折 ==========
class StudentDiscount final : public IDiscountStrategy {
public:
    double calc(double price) const override { return price * 0.85; }
    std::string name() const override { return "学生(85折)"; }
};

// ========== 具体策略 C：VIP 7 折 ==========
class VipDiscount final : public IDiscountStrategy {
public:
    double calc(double price) const override { return price * 0.70; }
    std::string name() const override { return "VIP(7折)"; }
};

// ========== 具体策略 D：满 200 减 50（活动规则也是策略） ==========
class FullReductionDiscount final : public IDiscountStrategy {
public:
    double calc(double price) const override {
        return price >= 200.0 ? price - 50.0 : price;
    }
    std::string name() const override { return "满200减50(活动)"; }
};

// ========== 上下文 Context：持有当前策略，转发计价请求 ==========
class Checkout {
public:
    // 构造注入：默认策略
    explicit Checkout(std::unique_ptr<IDiscountStrategy> s)
        : m_strategy(std::move(s)) {}

    // set 注入：运行时动态更换算法（旧策略随 unique_ptr 自动析构，无泄漏）
    void setStrategy(std::unique_ptr<IDiscountStrategy> s) {
        m_strategy = std::move(s);
    }

    double settle(double price) const {
        return m_strategy->calc(price);   // 委托给当前策略
    }
    std::string strategyName() const { return m_strategy->name(); }

private:
    std::unique_ptr<IDiscountStrategy> m_strategy;  // 组合优于继承
};

int main() {
    const double price = 240.0;   // 购物车原价
    std::cout << "商品原价: " << price << " 元\n\n";

    // 默认策略：普通用户
    Checkout checkout(std::make_unique<NormalDiscount>());
    std::cout << "[" << checkout.strategyName() << "] 应付: "
              << checkout.settle(price) << " 元\n";

    // 运行中换策略：学生结账
    checkout.setStrategy(std::make_unique<StudentDiscount>());
    std::cout << "[" << checkout.strategyName() << "] 应付: "
              << checkout.settle(price) << " 元\n";

    // 运行中换策略：VIP 结账
    checkout.setStrategy(std::make_unique<VipDiscount>());
    std::cout << "[" << checkout.strategyName() << "] 应付: "
              << checkout.settle(price) << " 元\n";

    // 运行中换策略：活动满减（业务方无需改动 Checkout 一行代码）
    checkout.setStrategy(std::make_unique<FullReductionDiscount>());
    std::cout << "[" << checkout.strategyName() << "] 应付: "
              << checkout.settle(price) << " 元\n";

    return 0;   // 所有对象在作用域结束时由 RAII 自动释放
}

程序输出：

商品原价: 240 元

[普通用户(无折扣)] 应付: 240 元
[学生(85折)] 应付: 204 元
[VIP(7折)] 应付: 168 元
[满200减50(活动)] 应付: 190 元

对比第 ② 节的坏代码：现在「加一种折扣」=「写一个新类 + 在 main 里注入一次」，Checkout、其他策略类、调用点统统不用改。代码量虽然略增，但每个类的职责单一、可单独测试、可独立复用——这正是用少量结构换长期可维护性。

在写自己的策略代码之前，先看一个惊人的事实：你每天用的 Qt 本身就是一个策略模式的巨型教科书案例——QStyle。Qt 控件不自己画自己：QPushButton 要绘制时，会调用 style()->drawControl(CE_PushButtonLabel, ...)，把绘制请求委托给当前的外观策略对象。Windows 风格、Fusion 风格、macOS 风格……就是一组可互相替换的「绘制算法策略」；QStyleFactory::create("Fusion") + QApplication::setStyle(...) 一行代码即可在运行时切换整套 UI 外观，而所有控件代码零改动。这就是为什么同一套 Qt 程序在 Windows、Linux、macOS 上长着不同的脸——不是控件写了三份，而是插了三种不同的 QStyle 策略。

下面我们自己实现一个完整的策略模式 Qt 6 程序：文档导出器——同一篇文档，可以导出为纯文本 / HTML / Markdown 三种格式，下拉框一换，导出算法即换。工程共四个文件，均为 Qt6 + C++17 标准写法。

exporter.h（抽象策略 + 三个具体策略 + 上下文）：

#ifndef EXPORTER_H
#define EXPORTER_H

#include <QString>

// ========== 抽象策略：所有「导出算法」的统一接口 ==========
class IExportStrategy {
public:
    virtual ~IExportStrategy() = default;
    virtual QString name() const = 0;                    // 策略名（下拉框显示）
    virtual QString render(const QString &title,
                           const QString &body) const = 0; // 渲染为目标格式
};

// ========== 具体策略 1：纯文本 ==========
class PlainTextExporter final : public IExportStrategy {
public:
    QString name() const override { return QStringLiteral("纯文本 (.txt)"); }
    QString render(const QString &title,
                   const QString &body) const override;
};

// ========== 具体策略 2：HTML 网页 ==========
class HtmlExporter final : public IExportStrategy {
public:
    QString name() const override { return QStringLiteral("HTML 网页 (.html)"); }
    QString render(const QString &title,
                   const QString &body) const override;
};

// ========== 具体策略 3：Markdown ==========
class MarkdownExporter final : public IExportStrategy {
public:
    QString name() const override { return QStringLiteral("Markdown (.md)"); }
    QString render(const QString &title,
                   const QString &body) const override;
};

// ========== 上下文 Context：持有当前导出策略并转发请求 ==========
class DocumentExporter {
public:
    explicit DocumentExporter(IExportStrategy *strategy = nullptr);

    void setStrategy(IExportStrategy *strategy);  // 运行时更换导出算法
    IExportStrategy *strategy() const;

    // 把导出请求委托给当前策略；未设置策略时返回空串
    QString exportDocument(const QString &title,
                           const QString &body) const;

private:
    IExportStrategy *m_strategy = nullptr;  // 非拥有指针：策略由外部管理生命周期
};

#endif // EXPORTER_H

exporter.cpp（具体策略实现）：

#include "exporter.h"

QString PlainTextExporter::render(const QString &title,
                                  const QString &body) const {
    return title + QStringLiteral("\n")
           + QStringLiteral("--------------------")
           + QStringLiteral("\n") + body;
}

QString HtmlExporter::render(const QString &title,
                             const QString &body) const {
    // toHtmlEscaped()：把正文中的 <>& 转义，避免破坏 HTML 结构
    return QStringLiteral("<!DOCTYPE html>\n<html>\n<head>\n")
           + QStringLiteral("<meta charset=\"utf-8\">\n<title>")
           + title.toHtmlEscaped() + QStringLiteral("</title>\n</head>\n")
           + QStringLiteral("<body>\n<h1>") + title.toHtmlEscaped()
           + QStringLiteral("</h1>\n<p>") + body.toHtmlEscaped()
           + QStringLiteral("</p>\n</body>\n</html>\n");
}

QString MarkdownExporter::render(const QString &title,
                                 const QString &body) const {
    return QStringLiteral("# ") + title + QStringLiteral("\n\n") + body;
}

DocumentExporter::DocumentExporter(IExportStrategy *strategy)
    : m_strategy(strategy) {}

void DocumentExporter::setStrategy(IExportStrategy *strategy) {
    m_strategy = strategy;   // 运行时替换算法对象
}

IExportStrategy *DocumentExporter::strategy() const { return m_strategy; }

QString DocumentExporter::exportDocument(const QString &title,
                                         const QString &body) const {
    if (!m_strategy)
        return {};
    return m_strategy->render(title, body);   // 委托：Context 不关心具体算法
}

main.cpp（客户端：组装界面，用下拉框切换策略）：

#include <QApplication>
#include <QComboBox>
#include <QHBoxLayout>
#include <QLabel>
#include <QLineEdit>
#include <QPushButton>
#include <QTextEdit>
#include <QVBoxLayout>
#include <QWidget>

#include <vector>
#include "exporter.h"

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

    // 策略对象池：栈上创建，生命周期覆盖整个窗口，故 Context 可用非拥有指针
    PlainTextExporter plain;
    HtmlExporter      html;
    MarkdownExporter  markdown;
    std::vector<IExportStrategy *> strategies{&plain, &html, &markdown};

    // 上下文：先注入默认策略（纯文本）
    DocumentExporter exporter(&plain);

    // ---------- 组装界面 ----------
    QWidget window;
    window.setWindowTitle(QStringLiteral("策略模式演示：文档导出器"));

    auto *titleEdit = new QLineEdit(QStringLiteral("C++/Qt 设计模式学习笔记"));
    auto *bodyEdit  = new QTextEdit(QStringLiteral(
        "今天是第 20 天，学习策略模式。\n算法与上下文解耦，运行时自由替换。"));
    auto *combo     = new QComboBox;
    combo->addItem(plain.name());
    combo->addItem(html.name());
    combo->addItem(markdown.name());

    auto *exportBtn = new QPushButton(QStringLiteral("导出预览"));
    auto *result    = new QLabel(QStringLiteral("（预览结果将显示在这里）"));
    result->setWordWrap(true);
    result->setTextInteractionFlags(Qt::TextSelectableByMouse);
    result->setAlignment(Qt::AlignTop | Qt::AlignLeft);

    // ---------- 信号槽：切换下拉框 = 运行时更换策略 ----------
    QObject::connect(combo, &QComboBox::currentIndexChanged,
                     [&](int index) {
        if (index >= 0 && index < static_cast<int>(strategies.size()))
            exporter.setStrategy(strategies[static_cast<std::size_t>(index)]);
    });

    // 点击按钮 = 把渲染请求委托给当前策略
    QObject::connect(exportBtn, &QPushButton::clicked, [&]() {
        result->setText(exporter.exportDocument(titleEdit->text(),
                                                bodyEdit->toPlainText()));
    });

    // ---------- 布局 ----------
    auto *root = new QVBoxLayout(&window);
    root->addWidget(new QLabel(QStringLiteral("标题：")));
    root->addWidget(titleEdit);
    root->addWidget(new QLabel(QStringLiteral("正文：")));
    root->addWidget(bodyEdit);
    auto *row = new QHBoxLayout;
    row->addWidget(new QLabel(QStringLiteral("导出格式：")));
    row->addWidget(combo, 1);
    row->addWidget(exportBtn);
    root->addLayout(row);
    root->addWidget(result, 1);

    window.resize(560, 480);
    window.show();
    return app.exec();   // 窗口为栈对象，退出时自动销毁全部子控件
}

CMakeLists.txt：

cmake_minimum_required(VERSION 3.16)
project(strategy_demo LANGUAGES CXX)

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

find_package(Qt6 REQUIRED COMPONENTS Widgets)

qt_add_executable(strategy_demo
    main.cpp
    exporter.cpp
    exporter.h
)
target_link_libraries(strategy_demo PRIVATE Qt6::Widgets)

编译运行：cmake -B build && cmake --build build && ./build/strategy_demo。在正文里输入文字、选择「HTML 网页」再点「导出预览」，你会看到 DocumentExporter 的代码一行没变，输出的却是完全不同的格式——这就是策略「可替换」的直观体验。若想真正落盘，只需在槽函数里加一个 QFile 写入，属于练习范畴（见第 ⑭ 节）。

以第 ⑤ 节的最小示例为主线，梳理一次完整的策略调用与切换流程：

1. 创建策略并注入：main 中 std::make_unique<NormalDiscount>() 在堆上创建具体策略对象，通过 Checkout 构造函数传入；std::move 把所有权转移给 Context 的 m_strategy 成员（RAII：离开作用域自动析构，无手动 delete、无泄漏）。
2. 委托调用：客户端调用 checkout.settle(240.0)。Context 不计算任何折扣，而是执行 m_strategy->calc(price)——这是虚函数调用，运行期通过 vtable 分派到当前对象的真实类型（NormalDiscount::calc），返回 240。
3. 运行时换策略：学生来结账，调用 checkout.setStrategy(std::make_unique<StudentDiscount>())。函数内部 m_strategy = std::move(s)：旧策略（NormalDiscount 对象）被 unique_ptr 析构释放，新策略接管。Context 内部只是换了一个指针，Checkout 类代码零修改。
4. 再次委托：下一次 settle(240.0) 走新的 vtable，调用 StudentDiscount::calc（240 × 0.85 = 204）。之后 VIP、满减策略同理——同一个 Context、同一个调用点，行为随注入的策略而变。

Qt 示例的流程与之一致，只是「换策略」的触发源从手写调用变成了信号槽：用户操作 QComboBox → 发出 currentIndexChanged 信号 → lambda 槽执行 exporter.setStrategy(...) → 用户点「导出预览」→ exportDocument 委托给新策略渲染。整个流程中，DocumentExporter 对「纯文本 / HTML / Markdown 的区别」一无所知，这正是策略模式的核心价值：把变化关进策略类的笼子里，Context 永远只面对那个稳定的接口。

策略模式的每一个设计决策，都对应一条可论证的工程收益：

• 开闭原则（OCP）：扩展开放、修改关闭。新增一种算法 = 新增一个策略类 + 在组装处注册一次。Context、其他策略、所有调用点全部零修改。第 ⑤ 节加「满减」时，Checkout 类一个字节都没动，这就是 OCP 的直接证据。
• 依赖倒置原则（DIP）：依赖抽象，不依赖具体。Context 只依赖 IDiscountStrategy 这个抽象接口，策略细节向下沉淀到叶子类。高层（结算流程）不再受低层（计价细节）变化的影响。
• 单一职责原则（SRP）：一个类只干一件事。每种算法独占一个类，类名即文档（StudentDiscount 就是「学生价算法」）。出 bug 时定位范围缩小到一个类；改需求时影响面也收缩到一个类。
• 组合优于继承：避免类爆炸。若用继承表达「用户类型 × 折扣活动」，3 种用户 × 4 种活动 = 12 个子类，且「VIP + 618 活动」这种叠加根本没法用单一继承表达；而策略模式下只需 3 + 4 = 7 个类，叠加通过「组合策略」或策略内部再组合实现，维度各自独立增长。
• 可测试性：策略是天然的测试单元。每个策略类可脱离 UI、脱离数据库单独实例化测试——assert(StudentDiscount().calc(200) == 170) 一行就是一个用例；测试组合从「全分支矩阵」坍缩为「每策略独立 + 少量集成用例」。
• 可配置、可插拔。策略对象可以由简单工厂或配置文件按名字创建（factory.create("vip")），业务上常用来做 A/B 实验、灰度开关——线上切换计价/推荐算法只需改配置，不用发版。
• 消除条件分支的「发散式修改」。类型枚举 + switch 的最大危害不是丑，而是「一个需求要改 N 个函数的 N 个分支」；策略模式把分支收敛为「一次注入」，新增逻辑只在一个地方出现。

设计代价（要诚实面对）：类数量增加、代码总行数略增、调用多一次虚函数间接跳转（现代 CPU 分支预测下开销可忽略，热点路径可用 std::function 或模板策略进一步优化）。策略模式的本质是用少量的结构冗余，换取长期的演进安全——在算法会频繁变化、需要独立演进的场景里，这笔交易非常划算。

把第 ② 节的坏代码继续「演进」两年，你会得到这样的世界：

场景一：switch 野蛮生长，核心函数变成「面条」。产品经理半年内加了 PLUS 会员、企业协议价、618、双 11、新客首单立减…… calcFinalPrice 的 switch 从 4 个 case 长到 20 个 case，还要处理叠加优先级（先会员折扣、再满减、再券），层层嵌套的 if 让任何一个新人都不敢动它——改坏了双 11 的定价，责任谁都担不起，于是大家选择「再加一个 case」，函数继续腐烂。

场景二：分支逻辑复制粘贴，改一处漏三处：

// 算积分：又要按用户类型复制一遍分支
double calcPoints(double amount, UserType type) {
    double base = amount;                       // 1 元 = 1 积分
    if (type == UserType::Vip) base *= 2.0;     // VIP 双倍积分
    if (type == UserType::Student) base *= 1.5; // 学生 1.5 倍
    // ...更多类型来了继续加
    return base;
}

// 算运费：还要再复制一遍「谁包邮」的判断
double shippingFee(double amount, UserType type) {
    if (type == UserType::Vip || type == UserType::Enterprise)
        return 0.0;                             // VIP/企业包邮
    return 10.0;
}

某天「PLUS 会员 8 折」上线，你记得改了 calcFinalPrice，却忘了 calcPoints 里 PLUS 该有的 3 倍积分——线上 bug。更糟的是这类 bug 没有编译期保护，只能靠测试撞出来，而分支组合的测试矩阵早已爆炸到没人维护。

场景三：用继承硬扛，子类爆炸。有人试图用继承解决：「VipOrder 继承 Order 覆写计价」。但 EnterpriseVipOrder、StudentVipOrder……类型一多，类数量呈笛卡尔积爆炸（N 种身份 × M 种活动）；而且计价规则混在订单类里，订单的序列化、状态流转、持久化代码被迫跟着每个新规则重新编译、重新测试——继承把「算法变化」和「对象生命周期」两条独立的轴焊死在一起。

场景四：枚举值泄漏到整个代码库。UI 层要 if (type == UserType::Vip) 决定显示金色徽章，日志层要判断类型打印不同文案，网络层要根据类型走不同接口——一个本应只属于「计价领域」的概念，污染了所有层。加一个新类型 = 全库搜索所有 switch 点，漏一个就是静默错误。

适合使用（3~5 个典型场景）：

1. 同一行为存在多种算法变体，且需要在运行时切换：压缩（zip/gzip/7z）、加密（AES/SM4/RC4）、排序（按价格/按销量/按评分）、导航路线（驾车/公交/骑行）。这是策略模式最经典的舞台。
2. 业务规则按「客户类型 / 渠道 / 场景」分化：计费规则（不同套餐计费）、折扣规则、税率计算、运费模板——规则经常新增或调整，且希望互不影响。
3. 代码中出现一长串按类型枚举的 if-else / switch，且分支体都是「一小段独立算法」：这正是重构信号——把每个分支体提取成策略类，switch 就消失了。
4. 算法需要被多个 Context 复用：同一个校验算法（如身份证校验）既要在注册流程用、也要在找回密码流程用——封装成策略/独立算法对象后随处可注入。
5. 希望算法可配置、可插拔（配置驱动 / 插件化 / A-B 实验）：策略 + 简单工厂 + 配置字符串，线上热切换算法而不用改业务代码。

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

1. 只有一个实现，且看不到第二个变体的影子：为一个永远不会变化的算法引入接口 + 类层次，属于纯浪费（YAGNI）。等第二个变体真的出现时再重构，成本极低。
2. 策略需要访问 Context 的大量内部状态：如果每个策略都要 Context 暴露七八个 getter 才能工作，接口会越变越宽、耦合不降反升——此时应考虑把算法放进 Context 内部（或改用模板方法/访问者）。
3. 策略之间共享大量公共逻辑：若 80% 的代码相同、只有 20% 不同，继承（模板方法）比策略更合适，避免每个策略类里重复那 80%。
4. 超高频调用路径（如每帧、每元素）：虚函数间接调用 + 对象分配的开销虽然小，但在纳秒级热路径上仍可能成为瓶颈；此时考虑模板策略（编译期绑定）或直接函数指针。

过度设计提醒：只有两三种简单变体、且几乎不变时，一个 std::function 成员 + 几个 lambda 就够用了——C++17 里策略模式有两种实现档位：轻量档（std::function/函数指针，适合无状态简单算法）与重量档（抽象基类 + 策略对象，适合有状态、多方法、需复用的算法族）。经验法则：从轻量档起步，当出现「策略需要持有状态」「策略有多个相关方法」「同一策略要注入多个 Context」时，再升级到重量档。设计模式是工具箱，不是勋章墙——用解决问题的成本去衡量，而不是用模式数量去炫耀。

对比模式	核心意图	与策略模式的关键差异
状态模式（State）	对象行为随内部状态改变而改变	二者结构几乎相同，但意图相反：State 中状态对象自己决定「下一个状态是谁」并自动切换（切换逻辑藏在状态类里），行为变化是自发的；Strategy 中策略之间互不知晓、绝不互相切换，由客户端显式选择。简单记忆：State 是「内部状态驱动」，Strategy 是「外部选择驱动」。
模板方法模式（Template Method）	基类定义算法骨架，子类覆写可变步骤	TM 用继承 + 覆写（白盒复用，编译期绑定，子类必须继承基类）；Strategy 用组合 + 委托（黑盒复用，运行期绑定，可自由替换）。同一个「折扣」需求：TM 把折扣写进 Order 的子类，Strategy 把折扣做成独立对象注入 Order。明天 Day 21 详解。
命令模式（Command）	把「请求/动作」封装成对象，支持排队、撤销、日志	Command 封装的是一次动作调用（含接收者与参数），关注「发起者与执行者解耦、动作可延迟/可撤销」；Strategy 封装的是一个算法，关注「算法可互换」。Command 常带 execute()/undo()，Strategy 通常只有单一算法方法。
桥接模式（Bridge）	把抽象与实现两个维度分离，各自独立演化	结构上与 Strategy 几乎一模一样（都是持有接口 + 委托），但 Bridge 是结构型模式，通常在设计期为了两个正交维度（如 形状×绘制API）而搭建，相对固定；Strategy 是行为型模式，在运行期为算法切换而存在。同一个类图，意图不同，归属不同。

一句话辨析：Strategy、State、Bridge 三者类图相似，区别全在意图——Bridge 是「结构上分层」，State 是「行为自动流转」，Strategy 是「算法按需插拔」。面试时先答意图，再谈结构，就不会混淆。

Qt 是策略模式的「重度用户」，以下三处最具代表性：

• QStyle 家族（最典型）：QStyle 是抽象策略接口，声明了几十个绘制/度量虚函数（drawControl、drawPrimitive、pixelMetric、polish……），即「一套 UI 绘制算法」的完整契约；QFusionStyle、QWindowsStyle、macOS 风格等是具体策略。任何控件绘制时都执行 style()->drawControl(CE_PushButton, ...)——把绘制请求委托给当前策略。QStyleFactory::create("Fusion") + app.setStyle(...) 即可运行时整体换肤，控件代码零改动。这正是「Context（控件）稳定、算法（外观）可换」的教科书级应用。想定制外观？不必改 Qt，继承 QProxyStyle（装饰器 + 策略的结合）覆写个别虚函数即可。
• QImageIOHandler / QImageReader：图片的编解码是典型算法族。Qt 为 PNG、JPEG、WEBP 等格式提供不同的 QImageIOHandler 插件实现；QImageReader（Context）根据文件头/后缀选择对应 handler，把读取请求委托给它。新增一种图片格式 = 新增一个 handler 插件，读取框架不动——策略 + 插件的经典组合。
• QStringConverter（Qt6 编码转换）：Qt6 用 QStringConverter 抽象了不同字符编码的转换算法（UTF-8、UTF-16、Latin-1……），配合 QStringDecoder/QStringEncoder 使用，按需选择具体编码策略。这是策略思想在基础设施层的体现。

可以总结出一条规律：凡是 Qt 中「以 Q 开头、名字像名词、内部一堆虚函数、通过工厂创建、可被 set 到某个对象上」的类（QStyle、QImageIOHandler、QTextCodec/QStringConverter），八成是策略或与策略近亲。读 Qt 源码时，看到「xxx->yyy() 的 yyy 是虚函数且 xxx 来自工厂」，就可以按策略模式的框架去理解它了。