4.设计模式-策略模式(Strategy)_设计模式策略模式的意图-CSDN博客

本文介绍了策略模式在解决支付场景中多种支付方式选择的问题，如何通过策略模式避免复杂的if...else逻辑，提高代码可维护性和扩展性。当支付方式如支付宝、微信支付等不断增多时，策略模式能有效降低耦合度，便于添加新的支付策略。通过将每个支付方式封装为单独的类，实现了支付策略的自由切换和独立扩展。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

strategy介绍

主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。

意图：定义一系列算法，把它们一个个封装起来，并且使它们可互相替换(变化)。该模式使得算法可独立于使用它的客户程序(稳定)而变化(扩展，子类化)。

如何解决：将这些算法封装成一个一个的类，通过工厂来实现任意地替换。

优点：

1、算法可以自由切换。
2、避免使用多重条件判断。
3、扩展性良好(每一个策略相当于一个类,减少依赖,松耦合)。

缺点：

1、策略类会增多。
2、所有策略类都需要对外暴露。

注意: 如果策略稳定不变的情况下,建议还是使用if…else,比如性别只有男女的情况、一周只有7天的情况.

实现场景

以支付支付宝、微信支付、银联支付及京东白条为例.

在不使用策略模式之前是这样写的:

//支付方式
enum PayMode {
       AliPay,
       WeChatPay ,
       JDPay
};

 
class Payment{
    PayMode mode;
public:
    bool pay(const Context& context){
        //...
        if (mode == AliPay){
            // 支付宝支付
        }
        else if (mode == WeChatPay){
            // 微信支付
        }
        else if (mode == JDPay){
            // 京东支付
        }
        //....
     }
};

假如以后又增加招商支付、信用卡支付等等的时候,我们都需要去增加一个enum值,然后添加else if语句, 维护起来也很难，尤其后续新增加不同情况的操作(信用卡支付未成功跳转到微信支付等等)，还需要新增加if…else,耦合度太高。

所以可以使用策略模式来将这些复杂的逻辑判断分成一个个单独的类，实现同一个接口或者继承于同一个父类.

写法如下所示: