不得不说，在很多业务中，这种模式用得真的很香

技术分享 2年前 (2024-04-27) 0 999+

故事

“不能在写if else来拓展当前系统了，现在已经有三个支付场景了......”工位上，小猫看着电脑，挠着头。

就在刚刚，小猫接到了一个新需求，需要和客户公司打通资产，形成资产联动。说白了就是需要定制化对接客户公司的支付资产体系。除了这次接到的之外。前面其实已经对接了三家了。由于每家对接规范都不一样，历史对接的时候为了尽快上线，都是直接搞个else的新路由分支，然后去实现支付，退款。

在小猫看来，就是在堆屎山。牵一发而动全身的感觉真的很不好。由于本次的需求留有的时间还是相当充裕的，所以小猫下定决心，打算利用这次的拓展，将原来不合理的地方用上设计模式将其重构掉。

深思熟虑很久，小猫下定决心打算用“策略模式”重构一番。

聊聊策略模式

说到策略模式，老猫觉得这种设计模式在实际开发中使用其实是相当频繁的。老猫工作到现在也在很多业务场景中使用过这样的设计模式。例如，上述小猫遇到的第三方支付集成的问题上。另外的还有商城搞活动，针对不同的用户下单行为提供不同的折扣或者返现等活动。再例如商城运营人员根据不同的加价策略去定在售商品的价格等。

老猫工作十年中，对接过很多外部企业或者单位的接口，若业务定义一样，只是接口协议不同的业务其实往往都可以用到策略模式。
提炼一下适用场景如下：

（1）系统中有很多类，而它们的区别仅仅在于行为不同。

（2）一个系统需要动态地在几种算法中选择一种。

在很多业务中，这种模式用起来真的很香，既能够摆脱成堆的“if else”（当然关于 if else的优化,又是另外一个故事了，有兴趣的小伙伴可以看看这篇文章【接手了个项目，被if..else搞懵逼了】），另外写出来的代码本身拓展性也会比较好。

那么我们来看看策略模式，并且基于小猫遇到的场景问题，咱们来撸一下实现代码。

策略模式解决多路支付通道问题

在定义支付行为的时候，我们首先定义出常规的支付行为，咱们可以用接口interface的形式定义出来，当然也可以用abstract类的方式定义出来。这里老猫使用后者来定义。代码如下：

/**  * @author 公众号：程序员老猫  */ public abstract class Payment {     //获取支付渠道的名称     public abstract String getName();      //查询用户余额     protected abstract BigDecimal queryBalance(String uid);      public PayState doPay(String uid, BigDecimal amount) {         if (queryBalance(uid).compareTo(amount) < 0) {             return new PayState(500, "支付失败", "账户余额不足");         }         return new PayState(200, "支付成功", "支付金额：" + amount);     } }

定义一个标准的支付状态类：

/**  * @author 公众号：程序员老猫  */ public class PayState {     private int code;     private String msg;     private Object data;      public PayState(int code, String msg, Object data) {         this.code = code;         this.msg = msg;         this.data = data;     }      public String toString() {         return ("pay state :[" + code + "]," + msg + ",order detail: " + data);     } }

接下来，咱们来模拟各个支付渠道，并且咱们能够知道在不同的支付渠道中，我们当前的账户余额是多少。咱们就拿用的比较多的微信、支付宝、京东支付等支付渠道来做模拟吧。

支付宝实现，并且账户中有900元：

public class AliPay extends Payment {     @Override     public String getName() {         return "支付宝";     }      @Override     protected BigDecimal queryBalance(String uid) {         return new BigDecimal(900);     } }

微信支付，并且账户中有300元：

public class WxPay extends Payment{     @Override     public String getName() {         return "微信";     }      @Override     protected BigDecimal queryBalance(String uid) {         return new BigDecimal(300);     } }

以此类推，京东支付。

public class JDPay extends Payment{     @Override     public String getName() {         return "京东白条";     }      @Override     protected BigDecimal queryBalance(String uid) {         return new BigDecimal(400);     } }

定义好各种单一支付通道之后，其实我们就要组装策略了。把上述支付通道，加载到策略路由类中。老猫觉得这个地方也是策略模式中比较核心的点。

/**  * @author 公众号：程序员老猫  */ public class PayStrategy {     public static final String ALI_PAY = "aliPay";     public static final String WX_PAY = "wxPay";     public static final String JD_PAY = "jdPay";     public static final String DEFAULT = "wxPay";      //初始化的时候装载支付行为策略     private static Map<String,Payment> paymentMap = new HashMap<>();      static {         paymentMap.put(ALI_PAY,new AliPay());         paymentMap.put(WX_PAY,new WxPay());         paymentMap.put(JD_PAY,new JDPay());         paymentMap.put(DEFAULT,new WxPay());     }      //调用的时候路由具体的支付策略     public static Payment get(String payKey){         if(!paymentMap.containsKey(payKey)){             return paymentMap.get(DEFAULT);         }         return paymentMap.get(payKey);     } }

接下来，我们就模拟用户下订单支付行为了，具体如下：

/**  * @author 程序员老猫  * 下单场景  */ public class Order {     private String uid; //用户Id     private String orderId; //订单Id     private BigDecimal orderAmount; //支付金额      public Order(String uid, String orderId, BigDecimal orderAmount) {         this.uid = uid;         this.orderId = orderId;         this.orderAmount = orderAmount;     }      public PayState doPay() {         return doPay(PayStrategy.DEFAULT);     }      public PayState doPay(String payKey) {         Payment payment = PayStrategy.get(payKey);         System.out.println("欢迎使用" + payment.getName());         System.out.println("本次交易金额：" + orderAmount);         return payment.doPay(uid, orderAmount);     } }

最终咱们来进行测试一下：

public class PayStrategyTest {     public static void main(String[] args) {         Order order = new Order("ktdaddy","20240425224901",new BigDecimal(245));          System.out.println(order.doPay(PayStrategy.ALI_PAY));     } }

结果输出：

欢迎使用支付宝 本次交易金额：245 pay state :[200],支付成功,order detail: 支付金额：245

上述基本就是策略模式的使用了。老猫觉得应该还是比较清晰的。咱们简单看一下最终的调用类图：

到这里很多小伙伴可能会问了，上面写的案例其实并没有结合我们实际的spring开发框架去实现策略模式，日常开发的过程中我们Java程序员主要用的还是spring框架。那么如果要结合咱们spring日常开发框架又是怎么去实现呢。那么接下来，咱们接着往下看。

SpringBoot下策略模式解决多路支付通道

其实核心的思想还是上面这几个要领，老猫在此不多做展开，只是给大家提供一些思路，然后提供一些简单的日常开发中使用的截图给大家参考。支付使用策略模式的核心的思想无非就下面两个。

（1）咱们需要不同的支付策略类。

（2）需要有路由支付策略类的路由类。

其实上面两个核心中，比较重要的还是第二点，咱们如果去初始化策略类。在上面案例中，老猫使用的静态方法块来装载各个策略方法。在spring中其实我们可以使用@PostConstruct注解，进行service策略的初始化装载。

如下首先定义一个标准的支付接口，并且实现一下：

public interface Payment {     //获取支付渠道的名称     String getCode();      PayState doPay(String uid, BigDecimal amount); }

然后实现这个接口，咱们举一个例子来说明

@Service public class JDPay implements Payment {      @Override     public String getCode() {         return "jdPay";     }      @Override     public PayState doPay(String uid, BigDecimal amount) {         return null;     } }

关键此时咱们看一下核心加载的地方。

/**  * 程序员老猫  **/ @Service public class PayStrategy {     @Autowired     private Payment[] payments;      //初始化的时候装载支付行为策略     private static Map<String, Payment> paymentMap = new ConcurrentHashMap<>();       @PostConstruct     private void initRouteMap() {         for (Payment externalPayService : payments) {             paymentMap.put(externalPayService.getCode(), externalPayService);         }     }      public Payment getPayment(String payCode) {         return paymentMap.get(payCode);     } }

上述就是结合spring的核心策略模式的实现方式，老猫这里没有展开，但是最精华的部分，老猫觉得已经说清楚了。当然基于@PostConstruct进行策略加载的方式只是一种。大家可以实现spring自带的InitializingBean，在 Spring 容器完成 bean 的属性注入后，会调用 afterPropertiesSet() 方法来执行初始化逻辑。