C++策略模式实战：从算法解耦到电商促销系统设计

1. 策略模式：从“硬编码”到“可插拔”的思维跃迁

如果你写过C++，大概率遇到过这样的场景：一个类里塞满了 if-else 或者 switch-case ，就为了处理同一类问题的不同算法。比如，一个支付模块，根据用户选择的支付方式（微信、支付宝、银行卡），调用不同的支付接口；或者一个排序工具，需要支持冒泡、快速、归并等多种排序算法。代码写着写着，这个类就变得臃肿不堪，每次新增一种算法，都得去修改这个核心类的源代码，不仅违反了开闭原则，测试起来也让人头疼。

策略模式（Strategy Pattern）就是来解决这个痛点的。它的核心思想特别直接： 将算法（策略）从使用它的上下文（Context）中分离出来，封装成一系列独立的类，使得它们可以相互替换 。听起来有点抽象？你可以把它想象成家里的工具箱。你需要拧螺丝时，不会把整个工具箱焊死在墙上，而是从里面拿出合适的螺丝刀（策略）来用。策略模式就是让你在代码里也能这么干——把“拧螺丝”这个动作（上下文）和“用哪把螺丝刀”（具体策略）解耦。

在C++里实现策略模式，我们主要依靠面向对象的三大支柱之一：多态。通过定义一个抽象的 策略接口（Strategy Interface） ，然后让各种具体的算法去实现这个接口。而那个需要使用算法的类（上下文），则持有一个指向这个抽象接口的指针或引用。这样一来，上下文根本不需要关心背后具体是哪个算法在工作，它只负责调用接口。想换算法？简单，给上下文“塞”一个新的策略对象进去就行了。

这种设计带来的好处是实实在在的。首先，它符合“对修改关闭，对扩展开放”的原则，新增策略只需添加新类，无需改动现有代码。其次，它消除了复杂的条件判断语句，让代码更清晰、更易于维护。最后，由于策略类通常是轻量级的、无状态的，它们也更容易进行单元测试。

2. 策略模式的核心结构：角色与协作关系

要彻底理解策略模式，不能只停留在“感觉”上，得把它拆开来看清楚里面每个零件是怎么咬合的。一个标准的策略模式通常包含三个核心角色，它们各司其职，共同完成算法的动态切换。

2.1 策略接口：定义算法的“合同”

策略接口（ Strategy ）是一个纯虚基类，它用抽象方法定义了所有支持算法必须遵守的“合同”。在C++中，我们通常这样声明：

class SortingStrategy {
public:
    virtual ~SortingStrategy() = default; // 虚析构函数，确保正确释放派生类资源
    virtual void sort(std::vector<int>& data) const = 0; // 纯虚函数，算法接口
};

这里有几个关键点：

1. 虚析构函数 ：这是C++多态基类的“黄金法则”。如果通过基类指针删除派生类对象，没有虚析构函数会导致派生类的析构函数不被调用，可能引发资源泄漏。 = default 让编译器生成默认实现，简洁又安全。
2. 纯虚函数 ： = 0 将这个函数声明为纯虚函数，意味着 SortingStrategy 是一个抽象类，不能直接实例化。它强制所有具体策略类都必须提供自己的 sort 实现。
3. const 成员函数 ：这里的 sort 被声明为 const ，表明这个操作不应该修改策略对象自身的状态。这对于无状态的策略类（比如纯算法）是合理的，也方便了上下文在多线程环境下的使用。

这个接口就是上下文和具体策略之间通信的唯一桥梁，它隔离了变化。

2.2 具体策略：算法的具体实现

具体策略类（ ConcreteStrategy ）继承自策略接口，并提供算法接口的具体实现。每个类封装一种独立的算法。

class BubbleSort : public SortingStrategy {
public:
    void sort(std::vector<int>& data) const override {
        // 实现冒泡排序算法
        for (size_t i = 0; i < data.size(); ++i) {
            for (size_t j = 0; j < data.size() - i - 1; ++j) {
                if (data[j] > data[j + 1]) {
                    std::swap(data[j], data[j + 1]);
                }
            }
        }
    }
};

class QuickSort : public SortingStrategy {
public:
    void sort(std::vector<int>& data) const override {
        // 实现快速排序算法（这里简化了递归实现）
        if (data.empty()) return;
        quickSortRecursive(data, 0, data.size() - 1);
    }
private:
    void quickSortRecursive(std::vector<int>& data, int low, int high) const {
        // 快速排序递归部分实现
        // ... (具体实现略)
    }
};

注意 override 关键字，这是C++11引入的，它明确告诉编译器（和读代码的人）：“我就是要重写基类的虚函数”。如果函数签名不小心写错了，编译器会直接报错，这能有效防止因笔误导致的难以调试的Bug。

2.3 上下文：算法的使用者与调度者

上下文（ Context ）是策略模式的关键。它持有一个指向策略接口的指针（或智能指针），并将具体的算法执行委托给这个策略对象。

class Sorter {
private:
    std::unique_ptr<SortingStrategy> strategy_; // 持有策略的智能指针

public:
    // 构造函数注入策略
    explicit Sorter(std::unique_ptr<SortingStrategy> strategy = nullptr)
        : strategy_(std::move(strategy)) {}

    // 设置器注入策略（用于运行时动态切换）
    void setStrategy(std::unique_ptr<SortingStrategy> strategy) {
        strategy_ = std::move(strategy);
    }

    // 执行排序（上下文的核心业务逻辑）
    void executeSort(std::vector<int>& data) const {
        if (strategy_) {
            std::cout << "开始使用策略进行排序...\n";
            strategy_->sort(data); // 委托调用
            std::cout << "排序完成。\n";
        } else {
            std::cout << "错误：未设置排序策略。\n";
        }
    }

    // 可能还有其他与排序相关的上下文方法...
};

上下文的精妙之处在于：

1. 对策略一无所知 ： Sorter 类完全不知道 BubbleSort 或 QuickSort 的存在，它只认识 SortingStrategy 这个接口。这实现了彻底的解耦。
2. 组合优于继承 ：上下文不是通过继承来获得算法能力，而是通过组合（持有）一个策略对象。这比构建复杂的继承层次要灵活得多。
3. 生命周期管理 ：这里使用了 std::unique_ptr ，这是一种独占所有权的智能指针。它明确表达了“上下文拥有这个策略对象”的语义，并且能自动管理内存，防止内存泄漏。构造函数和 setStrategy 方法通过 std::move 来转移所有权，既高效又安全。

注意：关于智能指针的选择 。 std::unique_ptr 是最常用、最轻量的选择，表示独占所有权。如果确实需要多个上下文共享同一个策略对象（虽然不常见），可以考虑 std::shared_ptr 。但绝对要避免使用原始指针，在现代C++中，手动 new 和 delete 是万恶之源，极易导致内存问题。

这三个角色通过一种松散的、基于接口的协作方式联系在一起。客户端代码（ main 函数或更高层的模块）负责创建具体的策略对象，并将其装配到上下文中。之后，客户端只需与上下文交互，算法的具体实现被完全隐藏了起来。这种结构使得算法族可以独立于使用它的客户端而变化，极大地提升了系统的灵活性。

3. 从理论到实践：一个完整的C++策略模式示例

理解了结构，我们用一个更贴近实际开发的例子来串联整个流程。假设我们在开发一个电商系统的折扣计算模块，不同的促销活动（如新人立减、满减、折扣券）有不同的计算规则。用策略模式来设计再合适不过。

3.1 定义策略接口与具体策略

首先，定义我们的策略接口 DiscountStrategy 。

// discount_strategy.h
#pragma once
#include <cstdint> // 使用固定宽度整数类型，更专业

class DiscountStrategy {
public:
    virtual ~DiscountStrategy() = default;
    // 计算折扣后的价格。originalPriceCents 是以分为单位的原始价格，避免浮点数精度问题。
    virtual std::int64_t calculate(std::int64_t originalPriceCents) const = 0;
    // 返回策略的描述，用于日志或UI显示
    virtual std::string getName() const = 0;
};

接着，实现几种具体的折扣策略。

// concrete_discount_strategies.h
#pragma once
#include "discount_strategy.h"
#include <string>

class NewUserDiscount : public DiscountStrategy {
private:
    static constexpr std::int64_t DISCOUNT_AMOUNT = 500; // 新人立减5元（500分）

public:
    std::int64_t calculate(std::int64_t originalPriceCents) const override {
        // 新人立减，保证价格不为负
        std::int64_t finalPrice = originalPriceCents - DISCOUNT_AMOUNT;
        return finalPrice > 0 ? finalPrice : 0;
    }

    std::string getName() const override {
        return "新人立减优惠";
    }
};

class ThresholdDiscount : public DiscountStrategy {
private:
    std::int64_t threshold_; // 满减门槛（分）
    std::int64_t reduction_; // 减免金额（分）

public:
    ThresholdDiscount(std::int64_t thresholdCents, std::int64_t reductionCents)
        : threshold_(thresholdCents), reduction_(reductionCents) {
        // 简单的参数校验
        if (threshold_ <= 0 || reduction_ <= 0) {
            throw std::invalid_argument("门槛和减免金额必须为正数");
        }
    }

    std::int64_t calculate(std::int64_t originalPriceCents) const override {
        if (originalPriceCents >= threshold_) {
            std::int64_t finalPrice = originalPriceCents - reduction_;
            return finalPrice > 0 ? finalPrice : 0;
        }
        return originalPriceCents; // 未达到门槛，原价
    }

    std::string getName() const override {
        return "满" + std::to_string(threshold_ / 100) +
               "元减" + std::to_string(reduction_ / 100) + "元优惠";
    }
};

class PercentageDiscount : public DiscountStrategy {
private:
    double percentage_; // 折扣率，如0.85代表85折

public:
    explicit PercentageDiscount(double percentage)
        : percentage_(percentage) {
        if (percentage_ <= 0.0 || percentage_ > 1.0) {
            throw std::invalid_argument("折扣率必须在(0.0, 1.0]区间内");
        }
    }

    std::int64_t calculate(std::int64_t originalPriceCents) const override {
        // 注意浮点数计算和四舍五入。商业计算务必谨慎！
        double finalPrice = static_cast<double>(originalPriceCents) * percentage_;
        return static_cast<std::int64_t>(std::round(finalPrice));
    }

    std::string getName() const override {
        int discount = static_cast<int>((1.0 - percentage_) * 100);
        return std::to_string(discount) + "折优惠";
    }
};

实操心得：价格计算与浮点数陷阱 在涉及金钱的计算中，绝对要避免直接使用 float 或 double 进行存储和关键计算。浮点数的二进制表示有精度损失，可能导致 0.1 + 0.2 != 0.3 这种经典问题。最佳实践是 以最小货币单位（如分、厘）为整数单位进行存储和计算 ，仅在最终显示时转换为元、角。上面的例子使用 std::int64_t （通常足够大）存储“分”。如果涉及更复杂的金融计算，可以考虑使用定点数库（如 boost::multiprecision::cpp_int ）。

3.2 构建上下文：订单类

现在，创建使用这些策略的上下文—— Order 类。

// order.h
#pragma once
#include "discount_strategy.h"
#include <memory>
#include <string>

class Order {
private:
    std::string orderId_;
    std::int64_t originalPriceCents_;
    std::unique_ptr<DiscountStrategy> discountStrategy_;
    std::int64_t finalPriceCents_;

    // 私有方法，用于重新计算最终价格
    void recalculateFinalPrice() {
        if (discountStrategy_) {
            finalPriceCents_ = discountStrategy_->calculate(originalPriceCents_);
        } else {
            finalPriceCents_ = originalPriceCents_; // 无优惠
        }
    }

public:
    Order(std::string orderId, std::int64_t originalPriceCents)
        : orderId_(std::move(orderId)),
          originalPriceCents_(originalPriceCents),
          discountStrategy_(nullptr),
          finalPriceCents_(originalPriceCents) {
        if (originalPriceCents_ < 0) {
            throw std::invalid_argument("订单价格不能为负");
        }
    }

    // 设置折扣策略，并触发重新计算
    void applyDiscount(std::unique_ptr<DiscountStrategy> strategy) {
        discountStrategy_ = std::move(strategy);
        recalculateFinalPrice();
        std::cout << "已应用优惠策略: " << discountStrategy_->getName() << std::endl;
    }

    // 移除折扣策略
    void removeDiscount() {
        discountStrategy_.reset();
        finalPriceCents_ = originalPriceCents_;
        std::cout << "已移除优惠策略。\n";
    }

    // 获取订单信息
    void printOrderDetails() const {
        std::cout << "订单ID: " << orderId_ << "\n"
                  << "商品原价: " << originalPriceCents_ / 100.0 << " 元\n";
        if (discountStrategy_) {
            std::cout << "应用优惠: " << discountStrategy_->getName() << "\n";
        } else {
            std::cout << "应用优惠: 无\n";
        }
        std::cout << "实付金额: " << finalPriceCents_ / 100.0 << " 元\n"
                  << "------------------------\n";
    }

    // 获取最终价格（单位：分）
    std::int64_t getFinalPriceInCents() const { return finalPriceCents_; }
};

这个 Order 类清晰地展示了上下文的职责：

1. 管理策略 ：通过 applyDiscount 和 removeDiscount 方法来设置和清除策略。
2. 委托计算 ：将价格计算的核心逻辑 recalculateFinalPrice 委托给持有的策略对象。
3. 维护状态 ：缓存计算结果 finalPriceCents_ ，避免每次查询都重复计算。
4. 资源管理 ：使用 std::unique_ptr 自动管理策略对象的生命周期。

3.3 客户端代码与运行演示

最后，看看客户端如何灵活地使用这些组件。

// main.cpp
#include "order.h"
#include "concrete_discount_strategies.h"
#include <iostream>
#include <vector>

int main() {
    try {
        // 创建一笔订单，原价120元（12000分）
        Order order("20231027001", 12000);
        order.printOrderDetails();

        // 场景1：应用新人立减优惠
        std::cout << "\n>>> 场景1：应用新人立减\n";
        order.applyDiscount(std::make_unique<NewUserDiscount>());
        order.printOrderDetails();

        // 场景2：运行时动态切换为满减优惠（满100减20）
        std::cout << "\n>>> 场景2：切换为满减优惠\n";
        order.applyDiscount(std::make_unique<ThresholdDiscount>(10000, 2000)); // 满100元减20元
        order.printOrderDetails();

        // 场景3：再次切换为折扣券（8折）
        std::cout << "\n>>> 场景3：切换为折扣券\n";
        order.applyDiscount(std::make_unique<PercentageDiscount>(0.8)); // 8折
        order.printOrderDetails();

        // 场景4：移除所有优惠
        std::cout << "\n>>> 场景4：移除优惠\n";
        order.removeDiscount();
        order.printOrderDetails();

        // 场景5：批量处理不同策略的订单（模拟）
        std::cout << "\n>>> 场景5：批量订单处理\n";
        std::vector<Order> orders;
        orders.emplace_back("A001", 8000);  // 80元订单
        orders.emplace_back("A002", 15000); // 150元订单
        orders.emplace_back("A003", 5000);  // 50元订单

        auto fullReduction = std::make_unique<ThresholdDiscount>(10000, 1500); // 满100减15

        for (auto& ord : orders) {
            if (ord.getFinalPriceInCents() >= 10000) { // 模拟业务逻辑：仅对满100元的订单应用满减
                ord.applyDiscount(std::make_unique<ThresholdDiscount>(*fullReduction)); // 注意：需要复制策略对象
            }
            ord.printOrderDetails();
        }

    } catch (const std::exception& e) {
        std::cerr << "程序发生异常: " << e.what() << std::endl;
        return 1;
    }
    return 0;
}

运行这个程序，你会看到订单价格随着不同策略的应用而动态变化。关键在于， Order 类的代码（上下文）在整个过程中 完全没有被修改 。我们只是通过注入不同的策略对象，就完全改变了它的行为。这就是策略模式的力量——将变化封装在独立的策略类中，使核心业务逻辑保持稳定。

4. 策略模式的经典应用场景深度剖析

策略模式绝非纸上谈兵的设计，它在C++的实际项目开发中有着极其广泛的应用。理解这些场景，能帮助你在遇到类似问题时，第一时间想到这个“工具箱”。

4.1 算法选择与替换：以排序和压缩为例

这是策略模式最直观的应用。当系统需要在多种算法中动态选择时，策略模式是首选。

场景一：数据排序器 我们前面的例子已经展示了排序。在实际的数据库中间件或数据分析库中，可能会根据数据规模、是否已部分有序、内存限制等因素，在快速排序、归并排序、堆排序甚至内省排序（IntroSort）之间动态切换。上下文（排序器）提供一个 setSortStrategy 接口，监控模块根据实时数据特征，选择最优策略注入。

场景二：文件压缩工具 考虑一个支持ZIP、GZIP、BZIP2等多种压缩格式的工具。可以定义一个 CompressionStrategy 接口，包含 compress 和 decompress 方法。具体策略类封装不同压缩库（如zlib, bzip2）的调用。上下文（压缩工具）根据用户选择或文件扩展名，决定使用哪个策略。这样，新增一种压缩格式（如LZ4），只需要添加一个新的策略类，压缩工具的核心代码纹丝不动。

class CompressionStrategy {
public:
    virtual ~CompressionStrategy() = default;
    virtual std::vector<char> compress(const std::vector<char>& data) = 0;
    virtual std::vector<char> decompress(const std::vector<char>& compressedData) = 0;
};

class ZipCompression : public CompressionStrategy { /* ... */ };
class GzipCompression : public CompressionStrategy { /* ... */ };

4.2 业务规则与策略：电商与游戏领域的实战

在业务系统中，策略模式能优雅地处理那些经常变化的业务规则。

场景一：电商促销引擎 这正是我们示例的延伸。大型电商的促销规则极其复杂：限时折扣、秒杀、会员价、跨店满减、优惠券叠加、预售定金膨胀等等。如果把这些逻辑全部用 if-else 写在订单类里，代码将变成无法维护的“屎山”。正确的做法是，将每一种促销规则定义为一个策略类（如 SeckillStrategy , MemberPriceStrategy , CouponCompositeStrategy ）。促销引擎（上下文）根据商品、用户、时间等上下文信息，从策略工厂或配置中加载一组适用的策略，并按优先级依次执行，计算最终价格。这种设计使得市场运营人员通过配置就能上线新活动，无需开发介入。

场景二：游戏中的角色行为与AI 在游戏开发中，一个NPC（非玩家角色）的行为可能根据玩家距离、自身血量、时间等因素改变。例如，一个怪物可能有“巡逻”、“追击”、“攻击”、“逃跑”几种行为状态。我们可以将每种行为定义为一个策略（ BehaviorStrategy ）。NPC（上下文）持有一个当前行为策略的引用。游戏主循环中，NPC的 update 方法会调用当前策略的 execute 方法。当触发事件（如玩家进入视野）时，一个专门的“决策模块”会评估条件，并为NPC切换新的行为策略（如从“巡逻”切换到“追击”）。这使得AI行为模块高度模块化，策划人员调整行为逻辑时，只需修改或替换对应的策略类。

4.3 跨平台与环境适配：渲染与序列化

当代码需要运行在不同平台或环境下，且不同环境需要不同实现时，策略模式是隔离平台相关代码的利器。

场景一：图形渲染后端 一个图形引擎可能需要支持OpenGL、DirectX、Vulkan甚至软件渲染。我们可以定义一个 RenderStrategy 接口，包含 drawMesh , setUniform 等方法。然后为每个图形API实现一个具体策略类（ OpenGLRenderer , DirectX11Renderer ）。引擎初始化时，根据当前操作系统和硬件能力，创建并注入相应的渲染策略。所有上层的渲染指令都通过这个抽象接口下发，实现了渲染逻辑与底层API的彻底解耦。

场景二：数据序列化/反序列化 系统可能需要将数据保存为JSON、XML、Protocol Buffers或MessagePack等不同格式。定义一个 SerializationStrategy 接口，包含 serialize 和 deserialize 方法。不同的格式对应不同的策略类。配置模块或网络通信模块（上下文）可以根据配置文件或协议头，动态选择序列化策略。这使得更换数据格式变得非常容易，也方便进行多种格式的兼容性处理。

4.4 测试与模拟：依赖注入的天然伙伴

策略模式极大地提升了代码的可测试性。由于依赖（算法）是通过接口注入的，在单元测试中，我们可以轻松地用“模拟对象”（Mock）或“桩”（Stub）来替换真实的策略。

例如，测试一个依赖复杂加密算法的支付模块。真实的加密算法可能很慢或者有外部依赖。我们可以创建一个 MockEncryptionStrategy ，它的 encrypt 方法直接返回一个固定的、预期的密文。这样，支付模块的单元测试就可以快速、稳定地运行，而不受加密算法的影响。这种通过注入来解耦依赖的技术，是依赖注入（Dependency Injection）和控制反转（IoC）思想的体现，而策略模式是实现它的经典结构。

5. 策略模式的高级技巧与实战避坑指南

掌握了基本用法和场景，我们再来深入一些高级话题和实践中容易踩的坑。这些经验往往是在真实项目中摸爬滚打后才能深刻体会的。

5.1 策略对象的创建与管理：工厂与单例

当具体策略类增多时，在客户端代码中直接 new 具体的策略类会引入依赖，也违背了“面向接口编程”的原则。通常，我们会引入 工厂模式 来负责策略对象的创建。

简单工厂模式（策略工厂） 创建一个 StrategyFactory 类，它提供一个静态方法，根据传入的枚举值或字符串，返回对应的策略对象。

enum class DiscountType { NewUser, Threshold, Percentage };

class DiscountStrategyFactory {
public:
    static std::unique_ptr<DiscountStrategy> create(DiscountType type, ... /* 其他参数 */) {
        switch (type) {
            case DiscountType::NewUser:
                return std::make_unique<NewUserDiscount>();
            case DiscountType::Threshold:
                return std::make_unique<ThresholdDiscount>(...);
            case DiscountType::Percentage:
                return std::make_unique<PercentageDiscount>(...);
            default:
                throw std::invalid_argument("未知的折扣类型");
        }
    }
};
// 使用
order.applyDiscount(DiscountStrategyFactory::create(DiscountType::Threshold, 10000, 2000));

这样，客户端代码只依赖工厂和抽象接口，不依赖任何具体策略类，耦合度进一步降低。

无状态策略与单例 如果你的策略类是无状态的（即不包含任何成员变量，或者只有常量），那么每次创建新对象就是一种浪费。可以考虑将其实现为 单例 ，或者更简单点，在工厂中返回静态对象的引用（或轻量级的 std::shared_ptr ）。

class NewUserDiscount : public DiscountStrategy {
    // ... 实现同上 ...
public:
    // 获取单例实例
    static const NewUserDiscount& getInstance() {
        static NewUserDiscount instance; // C++11保证静态局部变量线程安全地初始化
        return instance;
    }
private:
    NewUserDiscount() = default; // 构造函数私有化
};
// 工厂中返回引用
return std::unique_ptr<DiscountStrategy>(std::make_unique<NewUserDiscount>(NewUserDiscount::getInstance())); // 注意：这里需要策略类可拷贝或可克隆

注意：策略对象的拷贝问题 。如果策略对象有状态（比如 ThresholdDiscount 的门槛和减免金额），通常不能使用单例。在通过工厂返回时，如果使用 std::unique_ptr ，需要策略对象是可移动构造的。如果策略对象不可拷贝也不可移动，工厂可能需要接收参数并在内部构造。

5.2 策略模式与状态模式：辨析与选择

策略模式和状态模式（State Pattern）在UML类图上看起来几乎一模一样，都是有一个上下文，持有一个指向抽象接口的引用，并通过委托来执行行为。初学者很容易混淆。它们的核心区别在于 意图 ：

• 策略模式 ： 客户端主动选择 策略。策略代表的是 算法 或 规则 ，它们彼此独立，可以相互替换，以改变上下文的行为。客户端很清楚不同策略的差异，并负责在合适的时机进行切换。例如，用户在下单时主动选择“满减”或“折扣券”。
• 状态模式 ： 状态自身在特定条件下触发转换 。状态代表的是上下文对象的 内部状态 ，状态转换通常由上下文内部的事件或条件触发，对客户端是透明的。例如，TCP连接有“监听”、“已建立”、“已关闭”等状态，收到“SYN”包会从“监听”切换到“已建立”，这个转换是协议逻辑的一部分，不是客户端能随意选择的。

简单来说，策略是“怎么做”（How），状态是“是什么”（What）。如果你发现策略的切换逻辑非常复杂，且依赖于上下文自身的某些属性，那么你可能真正需要的是状态模式。

5.3 C++特性赋能：模板策略与 std::function

C++的泛型和函数对象提供了实现策略模式的另一种轻量级方式，有时比传统的面向对象方法更灵活、性能更好。

基于模板的策略模式 如果策略类型在编译期就能确定，可以使用模板。这种方式完全消除了运行时多态的开销（虚函数调用），适合性能敏感的场合。

template <typename SortingStrategy>
class Sorter {
private:
    SortingStrategy strategy_;
public:
    // 策略可以作为模板参数传入，也可以作为构造参数
    explicit Sorter(SortingStrategy strategy = {}) : strategy_(std::move(strategy)) {}

    void sort(std::vector<int>& data) {
        strategy_(data); // 假设策略是可调用对象
    }
};

// 策略实现为函数对象（仿函数）
struct BubbleSortFunctor {
    void operator()(std::vector<int>& data) const { /* 冒泡排序实现 */ }
};

struct QuickSortFunctor {
    void operator()(std::vector<int>& data) const { /* 快速排序实现 */ }
};

// 使用
Sorter<BubbleSortFunctor> bubbleSorter;
Sorter<QuickSortFunctor> quickSorter;

缺点是失去了运行时的动态切换能力，策略类型在编译期就固定了。

使用 std::function 作为策略接口 C++11的 std::function 可以存储任何可调用对象（函数、lambda、函数对象、绑定表达式等）。这提供了一种极其灵活的策略模式实现方式，特别适合策略逻辑简单、一次性使用的场景。

class Sorter {
private:
    std::function<void(std::vector<int>&)> sortingStrategy_;
public:
    void setStrategy(std::function<void(std::vector<int>&)> strategy) {
        sortingStrategy_ = std::move(strategy);
    }

    void executeSort(std::vector<int>& data) {
        if (sortingStrategy_) {
            sortingStrategy_(data);
        }
    }
};

// 客户端可以传入lambda表达式
Sorter sorter;
sorter.setStrategy([](std::vector<int>& vec) {
    std::sort(vec.begin(), vec.end());
});
sorter.executeSort(myData);

这种方式非常简洁，但 std::function 可能有一些小的运行时开销，并且接口的约束是隐式的（依赖函数签名），不如显式的接口类清晰。

5.4 性能考量与设计权衡

1. 虚函数开销 ：传统的基于继承的策略模式必然涉及虚函数调用，这会带来一次间接寻址和可能的分支预测失败。对于在 内层循环中每秒调用数百万次 的微小算法（比如比较两个整数），这个开销可能是不可接受的。此时，基于模板的策略或直接内联函数是更好的选择。但对于大多数业务逻辑（如订单计算、AI决策），虚函数开销微乎其微，可读性和灵活性更重要。
2. 对象创建开销 ：频繁创建和销毁策略对象（尤其是在循环中）可能带来内存分配开销。对于无状态策略，使用单例或静态实例。对于有状态策略，可以考虑使用 对象池 进行复用。
3. 设计复杂度 ：不要为了用模式而用模式。如果一个类只有一两个简单的、几乎不会变的算法，直接用 if-else 或者函数指针可能更简单明了。策略模式的价值在于管理 一系列经常变化或扩展的算法 。当变化点明确且可能增长时，引入策略模式就是有价值的投资。

6. 常见问题排查与调试技巧实录

即便理解了原理，在实际编码中依然会遇到各种问题。下面是我在多年C++开发中，围绕策略模式总结的一些典型“坑”和解决思路。

6.1 内存管理问题：悬挂指针与双重释放

这是使用原始指针时最常见的问题。

问题场景 ：上下文类用原始指针持有策略对象，并在析构函数中 delete 它。如果客户端代码将一个栈上对象的地址（ &localStrategy ）或者一个已被 delete 的对象的地址传给上下文，就会导致未定义行为（崩溃或数据损坏）。

解决方案 ：

• 首选智能指针 ：如示例中所示，使用 std::unique_ptr 。它明确了所有权归属（上下文独占），并自动管理生命周期。这是现代C++的黄金标准。
• 如果必须用原始指针 ：明确约定所有权。通常约定“上下文不负责策略对象的生命周期”，即策略对象由客户端创建和管理，上下文只使用它。这时，上下文应使用 裸指针或引用 ，并在文档中清晰说明。但这种方式容易出错，不推荐。

// 危险！容易导致悬挂指针。
class Context {
    Strategy* strategy_; // 原始指针
public:
    void setStrategy(Strategy* s) { strategy_ = s; } // 谁负责delete `s`？不明确。
};

// 安全！所有权清晰。
class Context {
    std::unique_ptr<Strategy> strategy_;
public:
    void setStrategy(std::unique_ptr<Strategy> s) { strategy_ = std::move(s); } // 所有权转移
};

6.2 策略接口设计缺陷：参数爆炸与版本兼容

问题场景 ：策略接口 doAlgorithm 最初只接收一个参数。后来新增的策略需要更多上下文信息（比如用户ID、时间戳），你不得不修改接口，为所有已有的策略类添加一个未使用的参数，或者创建接口的V2版本，导致代码混乱。

解决方案 ：

• 使用参数对象 ：将多个相关参数封装成一个结构体或类（ ContextInfo ）。这样，接口只需要一个参数，未来新增信息只需修改参数对象，接口本身保持稳定。
• 将上下文传入策略 ：有时策略需要反向调用上下文的方法来获取更多信息。可以将上下文对象的引用或指针作为参数传给策略方法。但要注意避免循环依赖。

struct CalculationContext {
    std::int64_t price;
    std::string userId;
    std::chrono::system_clock::time_point orderTime;
    // ... 其他可能需要的上下文
};

class DiscountStrategy {
public:
    virtual std::int64_t calculate(const CalculationContext& context) const = 0;
};

6.3 运行时策略切换的线程安全问题

问题场景 ：在多线程环境下，一个线程正在通过策略A执行计算，另一个线程调用了 setStrategy 将策略切换为B。这可能导致数据竞争或计算逻辑混乱。

解决方案 ：

• 加锁 ：在上下文的 setStrategy 和执行策略的方法（如 executeSort ）上加互斥锁（ std::mutex ）。这是最直接的方法，但会影响性能。
• 不可变上下文 ：设计上下文为不可变（Immutable）的。每次需要切换策略时，不是修改现有上下文，而是 创建一个包含新策略的新上下文对象 。函数式编程中常用此模式，它天然避免了并发修改问题。对于C++，这可能意味着更多的对象创建开销，需要权衡。
• 线程局部存储 ：如果策略是线程特定的，可以考虑使用 thread_local 变量来存储策略指针，这样每个线程都有自己的策略副本，互不干扰。

class ThreadSafeSorter {
private:
    std::unique_ptr<SortingStrategy> strategy_;
    mutable std::mutex mtx_; // 可变互斥锁

public:
    void setStrategy(std::unique_ptr<SortingStrategy> newStrategy) {
        std::lock_guard<std::mutex> lock(mtx_);
        strategy_ = std::move(newStrategy);
    }

    void executeSort(std::vector<int>& data) const {
        std::lock_guard<std::mutex> lock(mtx_); // 注意：const方法中锁必须是mutable的
        if (strategy_) {
            strategy_->sort(data);
        }
    }
};

6.4 策略组合与链式调用

有时，一个业务可能需要按顺序应用多个策略（比如先满减，再打折）。这超出了基础策略模式的范围。

解决方案 ：可以引入 组合模式 （Composite Pattern）或 职责链模式 （Chain of Responsibility）。

• 组合策略 ：创建一个 CompositeDiscountStrategy ，它内部维护一个策略列表。其 calculate 方法遍历所有子策略，依次应用折扣（注意应用顺序和互斥规则）。
• 职责链 ：每个策略决定自己是否能处理，以及是否传递给下一个策略。这更适用于处理请求/响应的场景。

class CompositeDiscountStrategy : public DiscountStrategy {
private:
    std::vector<std::unique_ptr<DiscountStrategy>> strategies_;
public:
    void addStrategy(std::unique_ptr<DiscountStrategy> strategy) {
        strategies_.push_back(std::move(strategy));
    }
    std::int64_t calculate(std::int64_t originalPriceCents) const override {
        std::int64_t currentPrice = originalPriceCents;
        for (const auto& strategy : strategies_) {
            currentPrice = strategy->calculate(currentPrice); // 将上一个策略的结果作为下一个的输入
        }
        return currentPrice;
    }
};

调试策略模式相关的问题，一个很有效的技巧是 增加日志 。在策略接口的调用前后、策略切换时，打印详细的日志信息，包括策略类型、输入参数、输出结果等。这能帮你快速定位是策略逻辑错误，还是策略切换时机不对。另外，确保为你的抽象策略接口编写全面的单元测试，模拟各种边界情况，这能从根本上减少Bug。