1. 项目概述为什么策略模式是C开发者的必备技能如果你写过一些C项目尤其是那些需要处理多种算法或业务规则的模块你肯定遇到过这样的场景一个核心功能比如数据排序、支付计算或者日志输出随着需求变化需要支持越来越多的实现方式。最开始你可能用if-else或者switch-case硬编码代码很快就变得臃肿不堪每次新增一种算法都要去修改核心类测试起来也心惊胆战生怕动了旧逻辑。这种时候策略模式就是你的救星。它不是什么高深莫测的“银弹”而是一种朴实无华、却极其有效的设计思想核心目标就一个将算法或策略的定义与使用它的客户端代码解耦。简单来说策略模式让你能像更换手机壳一样轻松地更换对象的行为。在C的语境下这通常意味着利用多态和接口将一系列可互换的算法封装成独立的类让它们可以独立于使用它们的客户而变化。我见过太多项目因为早期没考虑这种扩展性后期重构起来痛苦万分。掌握策略模式不仅能让你写出更清晰、更易维护的代码更是面试中高频出现的“八股文”考点是区分普通码农和具备设计思维工程师的一道坎。2. 策略模式的核心思想与结构拆解2.1 模式定义与UML类图解析策略模式属于行为型设计模式。它的官方定义是定义一系列算法将每个算法封装起来并使它们可以互相替换。策略模式让算法的变化独立于使用算法的客户。我们用最经典的例子来解释一个电商系统的折扣计算。不同的促销活动如普通折扣、满减、会员价就是不同的策略。如果不使用策略模式你的订单结算函数里可能会塞满各种if (activityType “DISCOUNT”) {...} else if (activityType “FULL_REDUCTION”) {...}。这种代码的坏处显而易见违反开闭原则对扩展开放对修改关闭增加新促销类型必须修改结算函数同时所有算法逻辑耦合在一起难以单独测试和维护。策略模式通过以下角色来解决这个问题策略接口一个抽象基类或纯虚类定义了所有具体策略必须实现的方法。在我们的例子里就是DiscountStrategy它有一个纯虚函数calculate(double price)。具体策略实现了策略接口的具体类。比如NormalDiscountStrategy、FullReductionStrategy、VIPDiscountStrategy每个类内部实现了自己独特的计算逻辑。上下文持有一个策略对象的引用并提供一个接口供客户端设置或切换策略。上下文类并不关心具体是哪个策略在工作它只通过策略接口来调用算法。在我们的例子里Order或PriceCalculator类就可以作为上下文。用一段简化的代码结构来展示这个关系// 策略接口 class DiscountStrategy { public: virtual ~DiscountStrategy() default; virtual double calculate(double originalPrice) const 0; }; // 具体策略A class NormalDiscountStrategy : public DiscountStrategy { private: double rate_; // 折扣率如0.9 public: explicit NormalDiscountStrategy(double rate) : rate_(rate) {} double calculate(double originalPrice) const override { return originalPrice * rate_; } }; // 具体策略B class FullReductionStrategy : public DiscountStrategy { private: double full_; // 满多少 double reduction_; // 减多少 public: FullReductionStrategy(double full, double reduction) : full_(full), reduction_(reduction) {} double calculate(double originalPrice) const override { if (originalPrice full_) { return originalPrice - reduction_; } return originalPrice; } }; // 上下文 class PriceCalculator { private: std::unique_ptrDiscountStrategy strategy_; // 持有策略的智能指针 public: void setStrategy(std::unique_ptrDiscountStrategy strategy) { strategy_ std::move(strategy); } double calculatePrice(double originalPrice) { if (!strategy_) { throw std::runtime_error(Discount strategy not set!); } return strategy_-calculate(originalPrice); } };这个结构清晰地将变化的折扣算法和不变的计算流程分离开来。2.2 C实现策略模式的关键技术点在C中实现策略模式有几个技术细节需要特别注意它们直接关系到代码的健壮性和现代性。1. 使用智能指针管理策略对象生命周期在上面的例子中我使用了std::unique_ptr。这是现代CC11及以上的推荐做法。它明确了上下文PriceCalculator独占策略对象的所有权。当PriceCalculator对象销毁时其持有的策略对象也会被自动销毁完美避免了内存泄漏。如果需要在运行时动态切换策略使用std::unique_ptr配合std::move是高效且安全的选择。在某些需要共享策略对象的场景下虽然不常见也可以考虑std::shared_ptr。2. 策略接口的析构函数必须为虚函数这是一个至关重要的细节。基类DiscountStrategy的析构函数被声明为virtual ~DiscountStrategy() default;。如果基类的析构函数不是虚函数那么当你通过基类指针删除一个派生类对象时只会调用基类的析构函数派生类的析构函数不会被调用可能导致资源泄漏。将其设为虚函数确保了通过基类接口删除对象时整个对象链能被正确销毁。3. 利用std::function和Lambda实现轻量级策略对于非常简单的策略比如只是一个简单的比较或计算专门创建一个类可能显得笨重。C11的std::function和Lambda表达式提供了另一种轻量级的实现方式。这种方式将策略从“对象”降维成了“函数”适用于算法逻辑极其简单的场景。class Sorter { public: using CompareStrategy std::functionbool(int, int); void setStrategy(CompareStrategy strategy) { compare_ std::move(strategy); } void sort(std::vectorint data) { if (!compare_) return; // 使用compare_进行排序例如在冒泡排序中比较元素 for (size_t i 0; i data.size(); i) { for (size_t j i1; j data.size(); j) { if (compare_(data[j], data[i])) { // 如果符合策略条件则交换 std::swap(data[i], data[j]); } } } } private: CompareStrategy compare_; }; // 使用 Sorter sorter; // 策略1升序 sorter.setStrategy([](int a, int b) { return a b; }); // 策略2降序 sorter.setStrategy([](int a, int b) { return a b; });这种方式极其灵活但牺牲了策略作为“类”的封装性无法轻易拥有复杂状态和明确的接口约束。它更适合回调、比较器等微小策略。注意std::function方式虽然灵活但过度使用会导致接口意图不清晰且策略逻辑复杂时不如类封装来得直观。我个人的经验是如果策略需要维护自身状态如折扣率、满减阈值或者策略可能在未来扩展出更多方法优先使用传统的类继承方式。3. 从理论到实战一个完整的游戏角色技能系统案例让我们脱离枯燥的电商例子构建一个更吸引人的场景一个简单的游戏角色技能系统。角色可以施展不同的攻击技能策略比如普通攻击、火焰攻击、冰冻攻击。每种攻击造成的伤害计算方式不同并且可能附带不同的效果如燃烧、减速。3.1 系统设计与类结构实现首先定义策略接口AttackStrategy。一个攻击行为至少需要知道攻击者和被攻击者并执行攻击逻辑。#include iostream #include memory #include string #include vector // 前向声明 class GameCharacter; // 策略接口攻击策略 class AttackStrategy { public: virtual ~AttackStrategy() default; // 执行攻击返回造成的伤害值 virtual int execute(GameCharacter attacker, GameCharacter target) 0; // 获取策略描述 virtual std::string getName() const 0; };接下来我们实现几个具体的攻击策略。为了让例子更生动我们假设GameCharacter类有一个health_属性和一个receiveDamage方法。// 具体策略普通攻击 class NormalAttack : public AttackStrategy { public: int execute(GameCharacter attacker, GameCharacter target) override; std::string getName() const override { return Normal Attack; } }; // 具体策略火焰攻击 class FireAttack : public AttackStrategy { private: int burnDamagePerTurn_ 2; // 燃烧每回合持续伤害 int burnTurns_ 3; // 燃烧持续回合 public: int execute(GameCharacter attacker, GameCharacter target) override; std::string getName() const override { return Fire Attack; } }; // 具体策略冰冻攻击 class IceAttack : public AttackStrategy { private: int slowEffectTurns_ 2; // 减速效果持续回合 public: int execute(GameCharacter attacker, GameCharacter target) override; std::string getName() const override { return Ice Attack; } };现在定义上下文GameCharacter。角色持有一个攻击策略并且可以动态切换。class GameCharacter { private: std::string name_; int health_; std::unique_ptrAttackStrategy attackStrategy_; public: GameCharacter(std::string name, int health) : name_(std::move(name)), health_(health), attackStrategy_(nullptr) {} void setAttackStrategy(std::unique_ptrAttackStrategy strategy) { attackStrategy_ std::move(strategy); std::cout name_ switched to attackStrategy_-getName() .\n; } void attack(GameCharacter target) { if (!attackStrategy_) { std::cout name_ has no attack strategy set!\n; return; } std::cout name_ uses attackStrategy_-getName() on target.name_ .\n; int damage attackStrategy_-execute(*this, target); target.receiveDamage(damage); } void receiveDamage(int damage) { health_ - damage; std::cout name_ receives damage damage. Health: health_ \n; if (health_ 0) { std::cout name_ is defeated!\n; } } bool isAlive() const { return health_ 0; } const std::string getName() const { return name_; } int getHealth() const { return health_; } };最后我们来补全具体策略的实现。这里为了简化我们直接输出效果在实际游戏中这些效果可能会关联到更复杂的状态机或效果管理器。// 普通攻击实现简单造成固定伤害 int NormalAttack::execute(GameCharacter attacker, GameCharacter target) { int baseDamage 10; // 假设攻击力为10 std::cout A straightforward strike.\n; return baseDamage; } // 火焰攻击实现造成较低直接伤害但附加燃烧效果 int FireAttack::execute(GameCharacter attacker, GameCharacter target) { int directDamage 7; std::cout The target is set on fire, taking directDamage damage and will burn for burnTurns_ turns ( burnDamagePerTurn_ damage per turn).\n; // 在实际项目中这里会将燃烧效果添加到目标的持续效果列表中 // 例如target.addEffect(std::make_uniqueBurnEffect(burnTurns_, burnDamagePerTurn_)); return directDamage; } // 冰冻攻击实现造成伤害并附加减速效果 int IceAttack::execute(GameCharacter attacker, GameCharacter target) { int directDamage 6; std::cout The target is chilled, taking directDamage damage and is slowed for slowEffectTurns_ turns.\n; // 例如target.addEffect(std::make_uniqueSlowEffect(slowEffectTurns_)); return directDamage; }3.2 客户端代码与运行演示现在我们可以编写一个简单的main函数来演示这个灵活的系统。int main() { // 创建角色 GameCharacter warrior(Warrior, 100); GameCharacter mage(Mage, 80); GameCharacter monster(Dragon, 150); // 战士初始使用普通攻击 warrior.setAttackStrategy(std::make_uniqueNormalAttack()); warrior.attack(monster); // 战士普通攻击龙 // 法师使用火焰攻击 mage.setAttackStrategy(std::make_uniqueFireAttack()); mage.attack(monster); // 法师火焰攻击龙 // 战斗中战士捡到一把冰霜之剑切换攻击策略 warrior.setAttackStrategy(std::make_uniqueIceAttack()); warrior.attack(monster); // 战士冰冻攻击龙 // 龙也可以有策略比如根据血量切换攻击模式这里省略实现 // 动态切换策略的核心优势在此体现无需修改GameCharacter类的attack方法 // 只需注入不同的策略对象行为就完全改变了。 return 0; }运行这个程序你会看到清晰的输出展示了不同策略的执行效果和动态切换的过程。这个案例虽然简单但完整展示了策略模式在游戏开发中的一个典型应用技能/行为系统。你可以轻松地添加新的攻击类型如雷电攻击、毒攻击只需创建新的AttackStrategy派生类而无需触动GameCharacter或其他攻击类型的代码。4. 策略模式在真实项目中的高级应用与变体掌握了基础用法后我们来看看策略模式在更复杂场景下的应用和一些实用的变体技巧。4.1 策略工厂集中管理策略对象的创建当具体策略类很多且它们的创建逻辑可能比较复杂例如需要从配置文件中读取参数时直接在客户端代码中new具体策略对象会使得创建逻辑分散且难以维护。这时可以引入一个策略工厂。class AttackStrategyFactory { public: static std::unique_ptrAttackStrategy createStrategy(const std::string type) { if (type normal) { return std::make_uniqueNormalAttack(); } else if (type fire) { // 假设火焰攻击的参数来自配置 return std::make_uniqueFireAttack(/* 可以从全局配置读取 burnDamage, turns */); } else if (type ice) { return std::make_uniqueIceAttack(); } else if (type lightning) { // 未来轻松扩展 // return std::make_uniqueLightningAttack(); } // 或者抛出异常 throw std::invalid_argument(Unknown strategy type: type); } }; // 使用工厂 auto strategy AttackStrategyFactory::createStrategy(fire); warrior.setAttackStrategy(std::move(strategy));工厂模式将对象的创建与使用分离使客户端代码更简洁并且将策略类型的判断逻辑集中到了一处便于管理。当需要添加新策略时只需修改工厂类。4.2 策略模式与模板的结合编译期策略对于性能要求极高的场景如游戏引擎、高频交易系统运行时多态虚函数调用带来的微小开销也可能是不可接受的。C的模板元编程提供了在编译期绑定策略的能力完全消除运行时开销。// 策略作为模板参数 template typename SortingStrategy class SorterContext { public: void sort(std::vectorint data) { SortingStrategy strategy; strategy.execute(data); } }; // 具体策略作为独立的可调用对象类或结构体 struct QuickSortStrategy { void execute(std::vectorint data) { std::sort(data.begin(), data.end()); // 简单示意实际是快速排序实现 std::cout Sorted with Quick Sort.\n; } }; struct BubbleSortStrategy { void execute(std::vectorint data) { // 实现冒泡排序... std::cout Sorted with Bubble Sort.\n; } }; // 使用 std::vectorint numbers {5, 2, 8, 1, 9}; SorterContextQuickSortStrategy quickSorter; quickSorter.sort(numbers); // 编译期已绑定为快速排序 SorterContextBubbleSortStrategy bubbleSorter; bubbleSorter.sort(numbers); // 编译期已绑定为冒泡排序这种方式中策略类型在编译时就已经确定通过模板实例化生成不同的SorterContext类型。execute调用是静态绑定的没有任何虚函数开销。缺点是策略无法在运行时动态切换灵活性降低。它适用于策略集合在编译时已知且固定的场景是C特有的一种高效实现方式常被称为“策略模式”的静态版本或“Policy-Based Design”。4.3 策略模式在标准库和流行框架中的应用策略模式的思想在C标准库中无处不在最典型的例子就是STL算法中的比较器和分配器。std::sort你可以传入一个自定义的比较函数或函数对象Lambda作为排序策略std::sort内部使用这个策略来比较元素。std::vectorPerson people; // 按年龄升序排序策略1 std::sort(people.begin(), people.end(), [](const Person a, const Person b) { return a.age b.age; }); // 按姓名降序排序策略2 std::sort(people.begin(), people.end(), [](const Person a, const Person b) { return a.name b.name; });STL容器的分配器std::vectorT, Allocator中的Allocator就是一个策略参数它定义了内存分配和释放的方式。你可以自定义分配器来实现内存池、调试内存跟踪等策略而无需修改vector本身的代码。在许多大型C项目或框架中如游戏引擎的渲染管线不同的渲染策略、网络库的IO多路复用模型select, poll, epoll策略、日志库的输出目的地控制台、文件、网络策略策略模式都是降低模块耦合度的核心手段。5. 避坑指南与最佳实践心得在实际项目中应用策略模式近十年我踩过不少坑也总结出一些让代码更健壮、更优雅的经验。5.1 常见陷阱与解决方案陷阱1策略对象持有上下文引用导致循环依赖或生命周期问题。有时策略的执行需要访问上下文的大量信息。一种偷懒的做法是在策略对象里保存一个指向上下文对象的指针或引用。// 危险的写法 class BadStrategy { Context* context_; // 持有上下文指针 public: explicit BadStrategy(Context* ctx) : context_(ctx) {} void execute() { // 使用context_... // 如果context_先于策略对象被销毁这里就是悬空指针程序崩溃。 } };解决方案尽量避免策略持有上下文的长期引用。如果策略确实需要上下文数据来决策应该通过execute方法的参数传递进去就像我们游戏例子中的attacker和target。如果数据很多可以考虑封装成一个轻量的ContextData结构体作为参数传递。陷阱2策略类膨胀每个策略一个类导致类数量爆炸。如果系统有上百种细微差别的算法每个都建一个类管理起来会很头疼。解决方案评估策略的差异程度。如果差异仅在于少数几个参数比如折扣率不同可以合并成一个类通过构造函数参数化配置。只有算法逻辑结构步骤、公式完全不同时才值得拆分为独立策略类。也可以考虑使用上面提到的std::function来封装极其简单的策略逻辑。陷阱3忽略了策略对象的创建成本。如果策略对象构造非常昂贵例如需要加载大量资源、建立网络连接在需要频繁切换策略的场景下反复创建销毁会成为性能瓶颈。解决方案考虑使用享元模式配合策略模式。如果策略是无状态的即execute方法不依赖对象内部状态只依赖参数那么一个策略类只需要一个实例所有上下文可以共享这个实例。如果策略有状态但状态可重置可以考虑使用对象池来复用策略对象。5.2 设计决策何时该用何时不该用应该使用策略模式的场景一个系统需要在多种算法或行为中动态选择一种。避免使用多重条件转移语句冗长的if-else或switch-case来定义这些行为。算法的具体实现细节需要对客户端隐藏客户端只关心接口。算法可能在未来会频繁增加或变更。可能不需要策略模式的场景如果算法永远只有一种或者很少变化直接硬编码更简单。如果算法非常简单只是一两行代码使用函数指针或std::function可能更轻量。如果各个算法之间完全没有共同接口强行抽象反而增加复杂度。5.3 性能考量与优化建议虚函数开销传统的基于继承的策略模式必然涉及虚函数调用。对于每秒调用上亿次的超高性能热点代码这可能是需要考虑的因素。此时可以评估是否能用模板策略编译期多态替代。但对于绝大多数业务逻辑和游戏逻辑虚函数开销可以忽略不计设计上的清晰度更重要。对象分配开销使用std::unique_ptr或new创建策略对象涉及堆内存分配。在性能关键的循环中频繁切换策略可能带来压力。对策是提前创建好策略对象并复用或者使用栈上对象配合模板如果策略类型编译期可知。缓存友好性策略对象通常较小但虚函数表指针的间接跳转可能对CPU指令缓存不友好。在极端优化场景下可以考虑使用基于标签的switch分发或函数指针数组但这会牺牲部分设计美感。我的建议是除非性能分析器明确告诉你这里是瓶颈否则优先保证代码的清晰和可维护性。策略模式是C工具箱里一把锋利而实用的瑞士军刀。它不解决所有问题但在“行为扩展”这个特定问题上它能将代码从僵化和混乱中拯救出来。理解其精髓并在合适的场景果断应用你的代码库会因此变得更加灵活和健壮。记住所有设计模式的最终目的都是为了应对变化。
1. 项目概述为什么策略模式是C开发者的必备技能如果你写过一些C项目尤其是那些需要处理多种算法或业务规则的模块你肯定遇到过这样的场景一个核心功能比如数据排序、支付计算或者日志输出随着需求变化需要支持越来越多的实现方式。最开始你可能用if-else或者switch-case硬编码代码很快就变得臃肿不堪每次新增一种算法都要去修改核心类测试起来也心惊胆战生怕动了旧逻辑。这种时候策略模式就是你的救星。它不是什么高深莫测的“银弹”而是一种朴实无华、却极其有效的设计思想核心目标就一个将算法或策略的定义与使用它的客户端代码解耦。简单来说策略模式让你能像更换手机壳一样轻松地更换对象的行为。在C的语境下这通常意味着利用多态和接口将一系列可互换的算法封装成独立的类让它们可以独立于使用它们的客户而变化。我见过太多项目因为早期没考虑这种扩展性后期重构起来痛苦万分。掌握策略模式不仅能让你写出更清晰、更易维护的代码更是面试中高频出现的“八股文”考点是区分普通码农和具备设计思维工程师的一道坎。2. 策略模式的核心思想与结构拆解2.1 模式定义与UML类图解析策略模式属于行为型设计模式。它的官方定义是定义一系列算法将每个算法封装起来并使它们可以互相替换。策略模式让算法的变化独立于使用算法的客户。我们用最经典的例子来解释一个电商系统的折扣计算。不同的促销活动如普通折扣、满减、会员价就是不同的策略。如果不使用策略模式你的订单结算函数里可能会塞满各种if (activityType “DISCOUNT”) {...} else if (activityType “FULL_REDUCTION”) {...}。这种代码的坏处显而易见违反开闭原则对扩展开放对修改关闭增加新促销类型必须修改结算函数同时所有算法逻辑耦合在一起难以单独测试和维护。策略模式通过以下角色来解决这个问题策略接口一个抽象基类或纯虚类定义了所有具体策略必须实现的方法。在我们的例子里就是DiscountStrategy它有一个纯虚函数calculate(double price)。具体策略实现了策略接口的具体类。比如NormalDiscountStrategy、FullReductionStrategy、VIPDiscountStrategy每个类内部实现了自己独特的计算逻辑。上下文持有一个策略对象的引用并提供一个接口供客户端设置或切换策略。上下文类并不关心具体是哪个策略在工作它只通过策略接口来调用算法。在我们的例子里Order或PriceCalculator类就可以作为上下文。用一段简化的代码结构来展示这个关系// 策略接口 class DiscountStrategy { public: virtual ~DiscountStrategy() default; virtual double calculate(double originalPrice) const 0; }; // 具体策略A class NormalDiscountStrategy : public DiscountStrategy { private: double rate_; // 折扣率如0.9 public: explicit NormalDiscountStrategy(double rate) : rate_(rate) {} double calculate(double originalPrice) const override { return originalPrice * rate_; } }; // 具体策略B class FullReductionStrategy : public DiscountStrategy { private: double full_; // 满多少 double reduction_; // 减多少 public: FullReductionStrategy(double full, double reduction) : full_(full), reduction_(reduction) {} double calculate(double originalPrice) const override { if (originalPrice full_) { return originalPrice - reduction_; } return originalPrice; } }; // 上下文 class PriceCalculator { private: std::unique_ptrDiscountStrategy strategy_; // 持有策略的智能指针 public: void setStrategy(std::unique_ptrDiscountStrategy strategy) { strategy_ std::move(strategy); } double calculatePrice(double originalPrice) { if (!strategy_) { throw std::runtime_error(Discount strategy not set!); } return strategy_-calculate(originalPrice); } };这个结构清晰地将变化的折扣算法和不变的计算流程分离开来。2.2 C实现策略模式的关键技术点在C中实现策略模式有几个技术细节需要特别注意它们直接关系到代码的健壮性和现代性。1. 使用智能指针管理策略对象生命周期在上面的例子中我使用了std::unique_ptr。这是现代CC11及以上的推荐做法。它明确了上下文PriceCalculator独占策略对象的所有权。当PriceCalculator对象销毁时其持有的策略对象也会被自动销毁完美避免了内存泄漏。如果需要在运行时动态切换策略使用std::unique_ptr配合std::move是高效且安全的选择。在某些需要共享策略对象的场景下虽然不常见也可以考虑std::shared_ptr。2. 策略接口的析构函数必须为虚函数这是一个至关重要的细节。基类DiscountStrategy的析构函数被声明为virtual ~DiscountStrategy() default;。如果基类的析构函数不是虚函数那么当你通过基类指针删除一个派生类对象时只会调用基类的析构函数派生类的析构函数不会被调用可能导致资源泄漏。将其设为虚函数确保了通过基类接口删除对象时整个对象链能被正确销毁。3. 利用std::function和Lambda实现轻量级策略对于非常简单的策略比如只是一个简单的比较或计算专门创建一个类可能显得笨重。C11的std::function和Lambda表达式提供了另一种轻量级的实现方式。这种方式将策略从“对象”降维成了“函数”适用于算法逻辑极其简单的场景。class Sorter { public: using CompareStrategy std::functionbool(int, int); void setStrategy(CompareStrategy strategy) { compare_ std::move(strategy); } void sort(std::vectorint data) { if (!compare_) return; // 使用compare_进行排序例如在冒泡排序中比较元素 for (size_t i 0; i data.size(); i) { for (size_t j i1; j data.size(); j) { if (compare_(data[j], data[i])) { // 如果符合策略条件则交换 std::swap(data[i], data[j]); } } } } private: CompareStrategy compare_; }; // 使用 Sorter sorter; // 策略1升序 sorter.setStrategy([](int a, int b) { return a b; }); // 策略2降序 sorter.setStrategy([](int a, int b) { return a b; });这种方式极其灵活但牺牲了策略作为“类”的封装性无法轻易拥有复杂状态和明确的接口约束。它更适合回调、比较器等微小策略。注意std::function方式虽然灵活但过度使用会导致接口意图不清晰且策略逻辑复杂时不如类封装来得直观。我个人的经验是如果策略需要维护自身状态如折扣率、满减阈值或者策略可能在未来扩展出更多方法优先使用传统的类继承方式。3. 从理论到实战一个完整的游戏角色技能系统案例让我们脱离枯燥的电商例子构建一个更吸引人的场景一个简单的游戏角色技能系统。角色可以施展不同的攻击技能策略比如普通攻击、火焰攻击、冰冻攻击。每种攻击造成的伤害计算方式不同并且可能附带不同的效果如燃烧、减速。3.1 系统设计与类结构实现首先定义策略接口AttackStrategy。一个攻击行为至少需要知道攻击者和被攻击者并执行攻击逻辑。#include iostream #include memory #include string #include vector // 前向声明 class GameCharacter; // 策略接口攻击策略 class AttackStrategy { public: virtual ~AttackStrategy() default; // 执行攻击返回造成的伤害值 virtual int execute(GameCharacter attacker, GameCharacter target) 0; // 获取策略描述 virtual std::string getName() const 0; };接下来我们实现几个具体的攻击策略。为了让例子更生动我们假设GameCharacter类有一个health_属性和一个receiveDamage方法。// 具体策略普通攻击 class NormalAttack : public AttackStrategy { public: int execute(GameCharacter attacker, GameCharacter target) override; std::string getName() const override { return Normal Attack; } }; // 具体策略火焰攻击 class FireAttack : public AttackStrategy { private: int burnDamagePerTurn_ 2; // 燃烧每回合持续伤害 int burnTurns_ 3; // 燃烧持续回合 public: int execute(GameCharacter attacker, GameCharacter target) override; std::string getName() const override { return Fire Attack; } }; // 具体策略冰冻攻击 class IceAttack : public AttackStrategy { private: int slowEffectTurns_ 2; // 减速效果持续回合 public: int execute(GameCharacter attacker, GameCharacter target) override; std::string getName() const override { return Ice Attack; } };现在定义上下文GameCharacter。角色持有一个攻击策略并且可以动态切换。class GameCharacter { private: std::string name_; int health_; std::unique_ptrAttackStrategy attackStrategy_; public: GameCharacter(std::string name, int health) : name_(std::move(name)), health_(health), attackStrategy_(nullptr) {} void setAttackStrategy(std::unique_ptrAttackStrategy strategy) { attackStrategy_ std::move(strategy); std::cout name_ switched to attackStrategy_-getName() .\n; } void attack(GameCharacter target) { if (!attackStrategy_) { std::cout name_ has no attack strategy set!\n; return; } std::cout name_ uses attackStrategy_-getName() on target.name_ .\n; int damage attackStrategy_-execute(*this, target); target.receiveDamage(damage); } void receiveDamage(int damage) { health_ - damage; std::cout name_ receives damage damage. Health: health_ \n; if (health_ 0) { std::cout name_ is defeated!\n; } } bool isAlive() const { return health_ 0; } const std::string getName() const { return name_; } int getHealth() const { return health_; } };最后我们来补全具体策略的实现。这里为了简化我们直接输出效果在实际游戏中这些效果可能会关联到更复杂的状态机或效果管理器。// 普通攻击实现简单造成固定伤害 int NormalAttack::execute(GameCharacter attacker, GameCharacter target) { int baseDamage 10; // 假设攻击力为10 std::cout A straightforward strike.\n; return baseDamage; } // 火焰攻击实现造成较低直接伤害但附加燃烧效果 int FireAttack::execute(GameCharacter attacker, GameCharacter target) { int directDamage 7; std::cout The target is set on fire, taking directDamage damage and will burn for burnTurns_ turns ( burnDamagePerTurn_ damage per turn).\n; // 在实际项目中这里会将燃烧效果添加到目标的持续效果列表中 // 例如target.addEffect(std::make_uniqueBurnEffect(burnTurns_, burnDamagePerTurn_)); return directDamage; } // 冰冻攻击实现造成伤害并附加减速效果 int IceAttack::execute(GameCharacter attacker, GameCharacter target) { int directDamage 6; std::cout The target is chilled, taking directDamage damage and is slowed for slowEffectTurns_ turns.\n; // 例如target.addEffect(std::make_uniqueSlowEffect(slowEffectTurns_)); return directDamage; }3.2 客户端代码与运行演示现在我们可以编写一个简单的main函数来演示这个灵活的系统。int main() { // 创建角色 GameCharacter warrior(Warrior, 100); GameCharacter mage(Mage, 80); GameCharacter monster(Dragon, 150); // 战士初始使用普通攻击 warrior.setAttackStrategy(std::make_uniqueNormalAttack()); warrior.attack(monster); // 战士普通攻击龙 // 法师使用火焰攻击 mage.setAttackStrategy(std::make_uniqueFireAttack()); mage.attack(monster); // 法师火焰攻击龙 // 战斗中战士捡到一把冰霜之剑切换攻击策略 warrior.setAttackStrategy(std::make_uniqueIceAttack()); warrior.attack(monster); // 战士冰冻攻击龙 // 龙也可以有策略比如根据血量切换攻击模式这里省略实现 // 动态切换策略的核心优势在此体现无需修改GameCharacter类的attack方法 // 只需注入不同的策略对象行为就完全改变了。 return 0; }运行这个程序你会看到清晰的输出展示了不同策略的执行效果和动态切换的过程。这个案例虽然简单但完整展示了策略模式在游戏开发中的一个典型应用技能/行为系统。你可以轻松地添加新的攻击类型如雷电攻击、毒攻击只需创建新的AttackStrategy派生类而无需触动GameCharacter或其他攻击类型的代码。4. 策略模式在真实项目中的高级应用与变体掌握了基础用法后我们来看看策略模式在更复杂场景下的应用和一些实用的变体技巧。4.1 策略工厂集中管理策略对象的创建当具体策略类很多且它们的创建逻辑可能比较复杂例如需要从配置文件中读取参数时直接在客户端代码中new具体策略对象会使得创建逻辑分散且难以维护。这时可以引入一个策略工厂。class AttackStrategyFactory { public: static std::unique_ptrAttackStrategy createStrategy(const std::string type) { if (type normal) { return std::make_uniqueNormalAttack(); } else if (type fire) { // 假设火焰攻击的参数来自配置 return std::make_uniqueFireAttack(/* 可以从全局配置读取 burnDamage, turns */); } else if (type ice) { return std::make_uniqueIceAttack(); } else if (type lightning) { // 未来轻松扩展 // return std::make_uniqueLightningAttack(); } // 或者抛出异常 throw std::invalid_argument(Unknown strategy type: type); } }; // 使用工厂 auto strategy AttackStrategyFactory::createStrategy(fire); warrior.setAttackStrategy(std::move(strategy));工厂模式将对象的创建与使用分离使客户端代码更简洁并且将策略类型的判断逻辑集中到了一处便于管理。当需要添加新策略时只需修改工厂类。4.2 策略模式与模板的结合编译期策略对于性能要求极高的场景如游戏引擎、高频交易系统运行时多态虚函数调用带来的微小开销也可能是不可接受的。C的模板元编程提供了在编译期绑定策略的能力完全消除运行时开销。// 策略作为模板参数 template typename SortingStrategy class SorterContext { public: void sort(std::vectorint data) { SortingStrategy strategy; strategy.execute(data); } }; // 具体策略作为独立的可调用对象类或结构体 struct QuickSortStrategy { void execute(std::vectorint data) { std::sort(data.begin(), data.end()); // 简单示意实际是快速排序实现 std::cout Sorted with Quick Sort.\n; } }; struct BubbleSortStrategy { void execute(std::vectorint data) { // 实现冒泡排序... std::cout Sorted with Bubble Sort.\n; } }; // 使用 std::vectorint numbers {5, 2, 8, 1, 9}; SorterContextQuickSortStrategy quickSorter; quickSorter.sort(numbers); // 编译期已绑定为快速排序 SorterContextBubbleSortStrategy bubbleSorter; bubbleSorter.sort(numbers); // 编译期已绑定为冒泡排序这种方式中策略类型在编译时就已经确定通过模板实例化生成不同的SorterContext类型。execute调用是静态绑定的没有任何虚函数开销。缺点是策略无法在运行时动态切换灵活性降低。它适用于策略集合在编译时已知且固定的场景是C特有的一种高效实现方式常被称为“策略模式”的静态版本或“Policy-Based Design”。4.3 策略模式在标准库和流行框架中的应用策略模式的思想在C标准库中无处不在最典型的例子就是STL算法中的比较器和分配器。std::sort你可以传入一个自定义的比较函数或函数对象Lambda作为排序策略std::sort内部使用这个策略来比较元素。std::vectorPerson people; // 按年龄升序排序策略1 std::sort(people.begin(), people.end(), [](const Person a, const Person b) { return a.age b.age; }); // 按姓名降序排序策略2 std::sort(people.begin(), people.end(), [](const Person a, const Person b) { return a.name b.name; });STL容器的分配器std::vectorT, Allocator中的Allocator就是一个策略参数它定义了内存分配和释放的方式。你可以自定义分配器来实现内存池、调试内存跟踪等策略而无需修改vector本身的代码。在许多大型C项目或框架中如游戏引擎的渲染管线不同的渲染策略、网络库的IO多路复用模型select, poll, epoll策略、日志库的输出目的地控制台、文件、网络策略策略模式都是降低模块耦合度的核心手段。5. 避坑指南与最佳实践心得在实际项目中应用策略模式近十年我踩过不少坑也总结出一些让代码更健壮、更优雅的经验。5.1 常见陷阱与解决方案陷阱1策略对象持有上下文引用导致循环依赖或生命周期问题。有时策略的执行需要访问上下文的大量信息。一种偷懒的做法是在策略对象里保存一个指向上下文对象的指针或引用。// 危险的写法 class BadStrategy { Context* context_; // 持有上下文指针 public: explicit BadStrategy(Context* ctx) : context_(ctx) {} void execute() { // 使用context_... // 如果context_先于策略对象被销毁这里就是悬空指针程序崩溃。 } };解决方案尽量避免策略持有上下文的长期引用。如果策略确实需要上下文数据来决策应该通过execute方法的参数传递进去就像我们游戏例子中的attacker和target。如果数据很多可以考虑封装成一个轻量的ContextData结构体作为参数传递。陷阱2策略类膨胀每个策略一个类导致类数量爆炸。如果系统有上百种细微差别的算法每个都建一个类管理起来会很头疼。解决方案评估策略的差异程度。如果差异仅在于少数几个参数比如折扣率不同可以合并成一个类通过构造函数参数化配置。只有算法逻辑结构步骤、公式完全不同时才值得拆分为独立策略类。也可以考虑使用上面提到的std::function来封装极其简单的策略逻辑。陷阱3忽略了策略对象的创建成本。如果策略对象构造非常昂贵例如需要加载大量资源、建立网络连接在需要频繁切换策略的场景下反复创建销毁会成为性能瓶颈。解决方案考虑使用享元模式配合策略模式。如果策略是无状态的即execute方法不依赖对象内部状态只依赖参数那么一个策略类只需要一个实例所有上下文可以共享这个实例。如果策略有状态但状态可重置可以考虑使用对象池来复用策略对象。5.2 设计决策何时该用何时不该用应该使用策略模式的场景一个系统需要在多种算法或行为中动态选择一种。避免使用多重条件转移语句冗长的if-else或switch-case来定义这些行为。算法的具体实现细节需要对客户端隐藏客户端只关心接口。算法可能在未来会频繁增加或变更。可能不需要策略模式的场景如果算法永远只有一种或者很少变化直接硬编码更简单。如果算法非常简单只是一两行代码使用函数指针或std::function可能更轻量。如果各个算法之间完全没有共同接口强行抽象反而增加复杂度。5.3 性能考量与优化建议虚函数开销传统的基于继承的策略模式必然涉及虚函数调用。对于每秒调用上亿次的超高性能热点代码这可能是需要考虑的因素。此时可以评估是否能用模板策略编译期多态替代。但对于绝大多数业务逻辑和游戏逻辑虚函数开销可以忽略不计设计上的清晰度更重要。对象分配开销使用std::unique_ptr或new创建策略对象涉及堆内存分配。在性能关键的循环中频繁切换策略可能带来压力。对策是提前创建好策略对象并复用或者使用栈上对象配合模板如果策略类型编译期可知。缓存友好性策略对象通常较小但虚函数表指针的间接跳转可能对CPU指令缓存不友好。在极端优化场景下可以考虑使用基于标签的switch分发或函数指针数组但这会牺牲部分设计美感。我的建议是除非性能分析器明确告诉你这里是瓶颈否则优先保证代码的清晰和可维护性。策略模式是C工具箱里一把锋利而实用的瑞士军刀。它不解决所有问题但在“行为扩展”这个特定问题上它能将代码从僵化和混乱中拯救出来。理解其精髓并在合适的场景果断应用你的代码库会因此变得更加灵活和健壮。记住所有设计模式的最终目的都是为了应对变化。
