做了这么多年C我越来越觉得策略模式被讲成了一个做题套路。面试八股里人人会背把算法封装成对象、运行时自由切换可真回到项目里几个关键决策根本没被说透用虚函数还是std::function策略对象归谁管往构造函数里塞还是暴露setStrategy以及——为什么好多项目写着写着又退化成了一堆if-else。这篇文章不打算复读教科书我把一次真实的订单配送费计算模块重构过程完整拆开。从最原始的switch-case开始到策略接口设计、三种C实现路线选型、工厂注册表落地再到我踩过的虚析构、对象切片、生命周期这些坑最后聊一聊策略模式怎么跟装饰器、状态机配合使用。全文代码可以直接拷进你的工程实验每个结论背后我都会解释为什么这么做。1. 从一段失控的switch-case说起策略模式到底想解决什么问题1.1 我接手的那段祖传计费代码先说场景。我接手过一个电商后端模块里面有个calcShippingCost函数负责给订单算配送费。第一版很干净普通快递、EMS、顺丰各一个case总共20多行。半年之后这函数膨胀到接近400行case从快递类型一路长到会员等级、优惠活动、地域附加费逻辑还互相嵌套比如double calcShippingCost(const Order order) { double cost 0.0; switch (order.shippingType) { case ShippingType::Standard: cost order.weight * 1.5 order.distance * 0.2; if (order.memberLevel 2) { cost * 0.9; } break; case ShippingType::Express: cost order.weight * 3.0 order.distance * 0.8 10.0; if (order.isRemote) { cost * 1.2; } break; // 后面还有十几个case每个里面还套着各种if } return cost; }这代码的问题不是缩进难看而是每次要加一个新的快递渠道就得打开这个函数往下再堆一个case。改的人小心翼翼测试的人要回归所有历史场景。更麻烦的是不同快递公司的计价方式差异很大有的按体积重算有的有首重续重有的跟下单时间挂钩把所有这些塞进一个switch纯粹是给自己埋雷。我第一次重构时没有直奔策略模式而是先把所有变体情况列了一遍。列完发现真正频繁变化的是计价规则其他业务逻辑下单、改地址、发货都相对稳定。计价规则之间互不依赖未来还会不断新增。这就是典型的策略模式应用场景。1.2 策略模式的核心把变化的维度抽成接口策略模式的本质不是消除分支而是把会变化的算法放到稳定的外壳之后。这个外壳就是策略接口业务代码只跟外壳打交道不关心背后具体是哪一种算法。用生活类比插座就三种孔位标准但插在上面的电器天差地别。你不需要为了吹风机改插座也不需要为了台灯改插座——因为接口稳定电器可变。对应到订单场景calcShippingCost里会变的部分应该从调用方手里抽出来。调用方只需要知道有一个能算配送费的东西就够了至于是普通快递还是加急那是运行时的策略选择问题。用这种思路重构后函数的骨架变成double calcShippingCost(const Order order, const ShippingStrategy strategy) { return strategy.calculate(order); }原先几百行的函数变成了一行调用。每次新增快递只加一个策略对象不再动核心业务代码。哪怕后面加了十种二十种计价方式calcShippingCost依然可以保持一行函数。1.3 判断该不该用策略模式的三个标准纸上谈兵没意思我给自己定了三条判断标准全部满足才上策略模式算法确实在变策略不止一种而且未来有较大概率继续增加。算法形态相似所有策略的输入输出轮廓一致只是计算过程不同。调用方想与具体算法解耦业务代码不希望知道每种算法的内部细节。如果一条都不满足策略模式就是过度设计。比如计价规则永远只有一种那switch写完就结束了没必要为了未来可能增加一堆类。这个未来可能是最容易让人写出过度代码的念头我在第5章还会展开讲。2. C里实现策略模式的三种路线别再只写虚函数了很多人一提到策略模式就条件反射写一个抽象基类、几个派生类这是经典写法没错但C的现代特性提供了不少替代路线。我建议三种都要掌握因为它们的适用场景完全不同。2.1 基于虚函数多态教科书路线工程里的基本盘这是最正统的实现方式。定义一个抽象策略接口具体策略继承它并重写虚函数上下文类持有策略的基类指针或引用class ShippingStrategy { public: virtual ~ShippingStrategy() default; virtual double calculate(const Order order) const 0; }; class StandardShipping : public ShippingStrategy { public: double calculate(const Order order) const override { return order.weight * 1.5 order.distance * 0.2; } }; class ExpressShipping : public ShippingStrategy { public: double calculate(const Order order) const override { return order.weight * 3.0 order.distance * 0.8 10.0; } };上下文类里用一个std::unique_ptrShippingStrategy来持有策略配合工厂或注册表创建。这条路线的好处是类型安全、意图清晰、可扩展性最强后面第4章我会讲生命周期和所有权的问题。如果你的项目里策略数量多、组合复杂优先选它。2.2 基于std::function的实现轻量、灵活、代价小如果策略只是一个简单的计算逻辑没必要强制建一堆类。C11开始std::function可以直接当一个策略容器using ShippingStrategy std::functiondouble(const Order); class Order { public: explicit Order(ShippingStrategy strategy) : strategy_(std::move(strategy)) {} void setStrategy(ShippingStrategy strategy) { strategy_ std::move(strategy); } double shippingCost() const { return strategy_(order_); } private: ShippingStrategy strategy_; Order order_; };用法很灵活Order order(std::make_uniqueOrderData(...)); order.setStrategy([](const Order o) { return o.weight * 3.0 o.distance * 0.8 10.0; });lambda、函数指针、函数对象、甚至绑定表达式都能塞进去不需要任何基类和虚函数。这种做法的最大优势是代码量少策略逻辑就地定义非常适合策略数量少、逻辑简单、只在一个组件内部使用的场景。不过它也有代价std::function有类型擦除的开销调用时不如直接虚函数快但绝大多数业务场景可以忽略而且如果lambda捕获了大对象拷贝策略时会把整个捕获对象一起拷存在性能隐患。我在第4章的坑里会细说。2.3 基于模板的实现把选择权交给编译期模板策略的思路完全不一样它不在运行时指定策略而是在编译期就把策略类型定死。策略就是一个实现了operator()的普通类型struct StandardShipping { double operator()(const Order order) const { return order.weight * 1.5 order.distance * 0.2; } }; struct ExpressShipping { double operator()(const Order order) const { return order.weight * 3.0 order.distance * 0.8 10.0; } }; template typename Strategy class Order { public: explicit Order(Strategy strategy) : strategy_(std::move(strategy)) {} double shippingCost() const { return strategy_(order_); } private: Strategy strategy_; Order order_; };使用的时候创建订单时指定策略类型OrderStandardShipping order; order.shippingCost();如果策略需要构造参数可以通过构造函数传入如果策略可以默认构造连参数都不用传。模板方案的性能最优编译器可以内联掉所有函数调用没有虚表、没有类型擦除。代价是类型固定之后运行时无法切换策略而且OrderStandardShipping和OrderExpressShipping是两个完全不同的类型不能放进同一个容器里做统一处理。2.4 三种路线怎么选一张表说清楚对比维度虚函数多态std::function模板策略运行时切换支持支持不支持性能开销虚函数调用极小类型擦除调用相对慢可内联理论最优代码量每个策略需要类定义最轻量lambda即可中等需要模板类型动态扩展性高可做策略工厂高注册表方便低类型已定死使用的存储方式指针/引用/智能指针值语义可拷贝值语义随对象存储适合场景策略多、结构复杂的大型系统策略少、逻辑简单的局部组件策略编译期确定、性能敏感我的个人偏好主业务中用虚函数多态因为它扩展性最好局部工具代码里用std::function因为它最省事涉及性能敏感路径、策略又不会在运行时变选模板。这三种不是互斥的一个系统里可以混着用。3. 实战重构订单配送费计算器的完整落地光讲理论没意思下面进入真正的重构过程。我把一章完整的落地路径走一遍从接口设计到具体策略实现再到上下文和工厂。3.1 定义策略接口注意接口要窄策略接口的设计核心是窄——接口越小实现者越不容易犯错调用者越不依赖多余信息。我一开始给ShippingStrategy设计了好几个方法calculateBaseCost、calculateSurcharge、isAvailable、getDescription。后来发现大多数策略只需要一个方法剩下的都是空实现违背了接口隔离原则。最终我砍掉了多余的只保留核心class ShippingStrategy { public: virtual ~ShippingStrategy() default; virtual double calculate(const Order order) const 0; };calculate接收整个Order对象而不是一堆散参数这样策略内部可以自己决定用哪些字段接口今后扩展起来也不用改签名。如果只传weight和distance哪天想用电商平台的memberLevel字段做折扣就得改接口所有实现都要跟着动。3.2 实现具体的策略类基于上面的接口我实现了四个具体策略class StandardShipping : public ShippingStrategy { public: double calculate(const Order order) const override { return order.weight * 1.5 order.distance * 0.2; } }; class ExpressShipping : public ShippingStrategy { public: double calculate(const Order order) const override { return order.weight * 3.0 order.distance * 0.8 10.0; } }; class SameDayShipping : public ShippingStrategy { public: double calculate(const Order order) const override { return order.weight * 5.0 order.distance * 1.5 30.0; } }; class FreeShipping : public ShippingStrategy { public: double calculate(const Order) const override { return 0.0; } };这四行策略本身很简单真正重要的是每个策略都只负责一件事。之前switch里那些会员折扣、偏远地区附加费我并没有直接塞进策略类而是留到第5章用组合策略的方式叠加。策略保持单一职责后续维护会轻松很多。3.3 搭建上下文类把策略带入业务逻辑上下文类就是业务代码和策略之间的桥梁。它负责持有策略、调用策略并且对外屏蔽策略细节class Order { public: explicit Order(std::unique_ptrShippingStrategy strategy) : strategy_(std::move(strategy)) {} void setStrategy(std::unique_ptrShippingStrategy strategy) { strategy_ std::move(strategy); } double shippingCost() const { if (!strategy_) { throw std::logic_error(shipping strategy not set); } return strategy_-calculate(*this); } private: std::unique_ptrShippingStrategy strategy_; };注意这里我用的是std::unique_ptr而不是裸指针原因在4.1会讲。setStrategy的存在意味着策略可以在运行时切换比如用户从普通快递改成加急快递不需要重新创建Order对象。这种运行时替换能力正是基于虚函数多态的实现方式最核心的价值。3.4 用工厂/注册表消灭switch-case阴影有了策略类还剩下一个棘手问题策略对象本身怎么创建你当然可以在业务代码里直接std::make_uniqueExpressShipping()可这样业务层又知道了具体策略类型以后增加策略还是要改调用方。更好的办法是引入一个工厂把根据类型创建策略的逻辑收拢到一处enum class ShippingType { Standard, Express, SameDay, Free }; class ShippingStrategyFactory { public: static std::unique_ptrShippingStrategy create(ShippingType type) { switch (type) { case ShippingType::Standard: return std::make_uniqueStandardShipping(); case ShippingType::Express: return std::make_uniqueExpressShipping(); case ShippingType::SameDay: return std::make_uniqueSameDayShipping(); case ShippingType::Free: return std::make_uniqueFreeShipping(); } throw std::invalid_argument(unknown shipping type); } };你可能觉得这不太对——switch又回来了。但请仔细想一下区别以前switch塞在整个业务逻辑中间每次加策略都要动核心函数现在switch被关在工厂这个唯一的变动点里业务层只依赖ShippingStrategyFactory::create耦合度低了很多。如果连这个switch都嫌烦可以用注册表做成完全查表式的class ShippingStrategyRegistry { public: using Creator std::functionstd::unique_ptrShippingStrategy(); void registerStrategy(std::string name, Creator creator) { creators_[std::move(name)] std::move(creator); } std::unique_ptrShippingStrategy create(const std::string name) const { auto it creators_.find(name); if (it creators_.end()) { throw std::invalid_argument(unknown strategy: name); } return it-second(); } private: std::unordered_mapstd::string, Creator creators_; };注册表的好处是能动态注册比如配置驱动解析配置文件往注册表里塞策略业务层完全不用感知。这在插件式架构里尤其好用。4. 我在C策略模式里踩过的坑很多博客讲完UML图就收工了但C的坑恰恰在代码之外。下面几个问题都是我真实踩过的每个都浪费了不少时间希望你绕开。4.1 忘了虚析构内存泄漏防不胜防这是最经典也最容易犯的错。如果你写了多态基类但没有把析构函数声明为virtual那么用基类指针删除派生类对象时只会调用基类的析构函数派生类部分的资源永远不会被释放。// 错误示范 class ShippingStrategy { public: virtual double calculate(const Order order) const 0; // 忘了写 virtual ~ShippingStrategy() default; };如果你持有的是std::vectorstd::unique_ptrShippingStrategy数组析构时会逐个delete基类指针派生类里new出来的资源就会泄漏。这个泄漏不会立刻暴露但跑压测时内存曲线会一路爬升。正确的做法很统一所有多态基类都写上一句virtual ~ShippingStrategy() default;别觉得这是小概率事件我见过好几个项目就是因为引用了第三方接口类漏了析构函数导致线上服务内存持续上涨。今天写策略基类时多打一行字省得将来熬夜查泄漏。4.2 对象切片值传递策略的翻车现场有次我图省事把上下文里的策略成员从std::unique_ptrShippingStrategy改成了ShippingStrategy直接存值心想反正算完就完事了。结果运行时每次调用calculate都跳到基类版本派生类的方法根本没执行——典型的对象切片。切片发生的原理是按值传递或按值存储时C会把派生类对象裁剪成基类部分丢掉所有派生类字段和方法覆盖。虚函数调用依赖虚表指针而切片后的对象虚表指针指向基类所以多态完全失效。防止切片的方法上下文、函数参数里用ShippingStrategy、ShippingStrategy*或std::unique_ptrShippingStrategy不要用ShippingStrategy值。如果策略逻辑真的很轻干脆用std::function方案别硬套虚函数多态。如果确实需要值语义可以考虑第2.3节的模板方案把策略类型作为模板参数存起来。4.3 空的std::function与生命周期管理在用std::function实现策略时有个特别容易忽视的坑一个默认构造的std::function是空的调用它会抛出std::bad_function_call。业务代码里如果从配置解析策略而配置漏了某个字段拿到了一个空函数调用时直接崩溃。所以用std::function方案时务必做空检查double shippingCost() const { if (!strategy_) { throw std::logic_error(shipping strategy not set); } return strategy_(*this); }另一个生命周期问题藏在lambda的捕获里。假设某个策略需要从数据库读取会员折扣你在lambda里捕获了一个数据库连接对象然后把这个lambda复制到多个订单上下文里——这意味着连接对象被复制了不止一份连接池可能被耗尽或者连接状态被多份副本交叉修改。我的建议是策略lambda尽量捕获值类型的小对象如果必须捕获大对象、连接、文件句柄等不可复制资源用std::shared_ptr包起来再捕获明确表达共享所有权的意图。4.4 策略模式被滥用的三个信号策略模式不是银弹。我在代码评审里见过把策略模式用得走火入魔的一个不到500行的模块硬是拆出8个策略类、5个工厂方法、30行配置文件改一个数字要跨3层。判断是否滥用的信号策略类只有一个实现且没有变化计划。当你只有一个具体策略时策略抽象就是纯浪费。如果以后真的多了再引入抽象也不迟。策略之间的差异只是几行代码。与其让每个策略变成独立的类不如用一个类加几个配置参数表达差异。策略内部还在用switch区分更细的类型。这往往说明策略粒度选错了策略作为算法维度的抽象本身不应该再按另一个维度分支。有一次我处理客户化需求渠道A和渠道B的差异只在一句是否包含包装加固费上。我一开始设计了两个策略类后来发现一个类加一个bool字段就够了。这种情况下策略模式就是过度设计少一个类就是少一份维护成本。5. 策略模式的高级玩法组合策略与状态联动基础版跑通之后你可以再往前走两步把策略组合起来、把策略和状态联动起来。这两个技巧让策略模式从替换算法进化为组合行为。5.1 用装饰器语法组合策略运费叠加怎么处理回到前面留的悬念偏远地区附加费、包装加固费怎么跟基础运费叠加如果直接在具体策略里加if就把策略搞得臃肿了。更好的方式是让一个策略包装另一个策略在原来的计算结果上做增量修饰这本质上是装饰器模式但和策略模式组合使用效果很好class SurchargeDecorator : public ShippingStrategy { public: SurchargeDecorator(std::unique_ptrShippingStrategy inner, double factor) : inner_(std::move(inner)), factor_(factor) {} double calculate(const Order order) const override { return inner_-calculate(order) * factor_; } private: std::unique_ptrShippingStrategy inner_; double factor_; };使用的时候auto base std::make_uniqueStandardShipping(); auto remoteStrategy std::make_uniqueSurchargeDecorator( std::move(base), 1.2);这样偏远地区不是一种新的快递策略而是对任意基础策略的一种修饰。你可以自由组合auto finalStrategy std::make_uniqueSurchargeDecorator( std::make_uniquePackagingDecorator( std::make_uniqueExpressShipping(), 5.0), 1.2);这个设计让我在客户需求变化时几乎不用改任何现有类只调整组合方式就能匹配加急加固偏远这类组合场景。5.2 策略与状态联动订单状态驱动的行为切换再进一步策略的选择往往和订单状态相关。比如待支付订单只允许标准配送支付后才允许换成加急发货后策略一律锁定。我落地的做法是策略切换不直接暴露给任意业务代码而是收口到状态变更方法里。class Order { public: void confirm() { state_ State::Confirmed; strategy_ std::make_uniqueExpressShipping(); } void ship() { if (state_ ! State::Confirmed) { throw std::logic_error(cannot ship before confirmation); } state_ State::Shipped; } private: State state_; std::unique_ptrShippingStrategy strategy_; };这样每次状态迁移伴随的策略切换都被封装在特定方法里业务调用方只需要order.confirm()不需要知道确认后要把策略换成加急这个细节。策略和状态的耦合被内聚到了一起而不是散落在业务代码的各个角落。5.3 什么时候真的不值得用策略模式最后说说我的边界判断。如果你的策略只有一种实现或者未来几乎不可能有新的实现直接写普通函数就完了。如果策略之间的差异只是几个参数用一个类加字段或配置项解决就好。如果策略会被频繁切换但切换点只有一个可以保留策略模式并顺手做一个简单的工厂如果切换点分散在各处说明把策略暴露得太广了可以考虑把策略选择收拢到状态机里。我也试过用std::variant std::visit来处理策略在策略数量不多且类型固定时它比多态更紧凑、更安全。但一旦策略数量会动态增加variant的类型集合也需要同步修改维护成本就上去了。说到底策略模式的价值在于管理变化而不是消灭变化。我用一个非常朴素的判断标准今天写这个抽象能不能让明天加新功能时彻底不用碰老代码能就值得写不能先别写。这不是什么大道理但每次重构到后半夜我都会想起这句话。