码迷,mamicode.com
首页 > 其他好文 > 详细

聚合支付业务的设计中的策略模式

时间:2020-06-03 15:41:25      阅读:99      评论:0      收藏:0      [点我收藏+]

标签:发送   封装   getc   模拟   分享   href   ogr   src   operator   

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接口。这个接口用来声明每一种方式的独立执行策略,用来封装具体策略的特有算法逻辑。

  • ConcreteStrategyStrategy的实现类。实现了不同策略的算法逻辑。比如每种支付的调用细节等等。

  • Context上下文。它通过策略接口来引用了具体的策略并使用具体的策略来执行逻辑,同时所有策略的共性也可以在该类中进行统一处理。在聚合支付需求中我们传入一个策略,先执行支付前的逻辑,然后使用策略,策略执行完毕后,再执行后置的共性逻辑。

  • Client客户端。创建策略对象并传递给上下文Context,然后由上下文运行具体的策略。

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

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

 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. 总结

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

“大清亡于闭关锁国,学习技术需要交流和资料”。 在这里我给大家准备了很多的学习资料免费获取,包括但不限于java进阶学习资料、技术干货、大厂面试题系列、技术动向、职业生涯等一切有关程序员的分享.

java进阶方法笔记,学习资料,面试题,电子书籍免费领取,让你成为java大神,追到自己的女神,走向人生巅峰

聚合支付业务的设计中的策略模式

标签:发送   封装   getc   模拟   分享   href   ogr   src   operator   

原文地址:https://www.cnblogs.com/coderjava/p/13037525.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!