设计模式:从聚合支付业务的设计来聊聊策略模式

1. 前言

移动支付目前在国内已经是非常普及了，连楼下早餐摊的七十多岁大妈也使用支付宝和微信支付卖鸡蛋饼。如果让你做一个App你肯定要考虑多个渠道支付，以保证获客渠道。如果让你来接入多种支付渠道你会怎么设计？

2. 通常写法

一般下面这种写法很容易被创造出来：

    public boolean pay(BigDecimal amount){

        boolean ret =false;
        if (alipay){
            //todo 支付宝的逻辑
        }else if (wechatpay){
            //todo 微信支付的逻辑
        }else if (ooxx){
           // …… 
        }
        return ret;
    }

如果集成了四五种支付，这个代码就没法看了少说几千行，而且改动某个支付的逻辑很容易改了其它支付的逻辑。因此需要合理的设计来避免这种风险。

3. 策略模式

大部分的支付可以简化为这个流程：

中间的发起支付前逻辑和支付后处理逻辑是客户端的自定义业务逻辑，向支付服务器发送的请求只会携带对应支付服务器特定要求的参数调用不同的支付SDK。所以我们分别建立对应支付方式的策略来隔离区分它们，降低它们的耦合度。当准备支付时我们只需要选择对应的策略就可以了。

这就用到了设计模式中的策略模式：

结合上面的类图，我们就来结合着需求来聊聊策略模式中的主要几个角色。

• Strategy接口。这个接口用来声明每一种方式的独立执行策略，用来封装具体策略的特有算法逻辑。
• ConcreteStrategy是Strategy的实现类。实现了不同策略的算法逻辑。比如每种支付的调用细节等等。
• Context上下文。它通过策略接口来引用了具体的策略并使用具体的策略来执行逻辑，同时所有策略的共性也可以在该类中进行统一处理。在聚合支付需求中我们传入一个策略，先执行支付前的逻辑，然后使用策略，策略执行完毕后，再执行后置的共性逻辑。
• Client客户端。创建策略对象并传递给上下文Context，然后由上下文运行具体的策略。

结合业务逻辑是这样的：请求到达客户端，客户端根据请求中包含的支付渠道来构建对应的策略对象并把它交给上下文对象去执行支付流程。

然后我们就可以分别为支付宝、微信支付、银联支付构造三个策略对象 AliPayStrategy、WechatPayStrategy、UnionPayStrategy ，我们来模拟一下执行策略：

public class Client {

    public static void main(String[] args) {
        // 获取请求中的支付渠道标识
        String code = "p01";
        PayStrategy payStrategy = null;
        PayRequest request = null;

        if (PayType.ALI.getCode().equals(code)) {
            //组装为支付宝支付策略
            payStrategy = new AliPayStrategy();
            // 构造支付宝请求参数
            request = new AliPayRequest();
        }
        if (PayType.WECHAT.getCode().equals(code)) {
            //组装为微信支付策略
            payStrategy = new AliPayStrategy();
            // 构造微信支付请求参数
            request = new WechatPayRequest();
        }

        if (PayType.UNION.getCode().equals(code)) {
            //组装为银联支付策略
            payStrategy = new UnionPayStrategy();
            // 构造银联支付请求参数
            request = new UnionPayRequest();
        }

        if (Objects.nonNull(payStrategy)) {
            PayContext payContext = new PayContext();
            payContext.setPayStrategy(payStrategy);
            payContext.pay(request);
        }
    }
}

我们拿到请求中的支付标识，然后初始化对应的支付策略，封装指定的请求参数，交给上下文对象PayContext 来执行请求。如果你再增加什么ApplePay之类的去实现ApplePayStrategy就行了。

4. 优缺点

策略模式并不都带来正面的作用。

4.1 优点

• 我们将算法的实现和算法的使用进行了隔离，算法实现只关心算法逻辑，使用算法只关心什么条件下使用什么算法。
• 开闭原则，无需修改上下文对象，想扩展只需要引入新的策略。
• 运行时根据条件动态的去切换算法。
• 适应个性的同时也可以兼容共性。

4.2 缺点

• 客户端必须明确知道激活策略的条件。
• 引入太多的策略类。
• 可被一些函数式接口所代替。伪代码Pay.request(data).strategy(data->{ })。

5. 总结

策略模式也是很常见而且有着广泛使用场景的设计模式。今天我们从聚合支付来学习了策略模式，对它的优缺点也进行了一个分析。随着函数式编程的普及，策略模式开始被逐渐的代替，但是它依然值得我们去学习。