2020年6月公众号码农小胖哥原创文章转发第一名将送全新《Spring Boot实战》实体书一本,该书是学习热门框架 Spring Boot的经典之作。你不再需要依靠运气,而是勤奋。截止统计日期2020年6月30日,统计数据以官方公众号工具为准,运营人员不参加活动,本次活动图书由掘金社区赞助。
前几天讲了设计模式中的命令模式,今天来看看另一个模式。移动支付目前在国内已经是非常普及了,连楼下早餐摊的七十多岁大妈也使用支付宝和微信支付卖鸡蛋饼。如果让你做一个App你肯定要考虑多个渠道支付,以保证获客渠道。如果让你来接入多种支付渠道你会怎么设计?
一般下面这种写法很容易被创造出来:
public boolean pay(BigDecimal amount){ boolean ret =false; if (alipay){ //todo 支付宝的逻辑 }else if (wechatpay){ //todo 微信支付的逻辑 }else if (ooxx){ // …… } return ret; }
如果集成了四五种支付,这个代码就没法看了少说几千行,而且改动某个支付的逻辑很容易改了其它支付的逻辑。因此需要合理的设计来避免这种风险。
大部分的支付可以简化为这个流程:
中间的发起支付前逻辑和支付后处理逻辑是客户端的自定义业务逻辑,向支付服务器发送的请求只会携带对应支付服务器特定要求的参数调用不同的支付SDK。所以我们分别建立对应支付方式的策略来隔离区分它们,降低它们的耦合度。当准备支付时我们只需要选择对应的策略就可以了。
这就用到了设计模式中的策略模式:
结合上面的类图,我们就来结合着需求来聊聊策略模式中的主要几个角色。
结合业务逻辑是这样的:请求到达客户端,客户端根据请求中包含的支付渠道来构建对应的策略对象并把它交给上下文对象去执行支付流程。
然后我们就可以分别为支付宝、微信支付、银联支付构造三个策略对象 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
就行了。
策略模式并不都带来正面的作用。
Pay.request(data).strategy(data->{ })
。策略模式也是很常见而且有着广泛使用场景的设计模式。今天我们从聚合支付来学习了策略模式,对它的优缺点也进行了一个分析。随着函数式编程的普及,策略模式开始被逐渐的代替,但是它依然值得我们去学习。感谢你的阅读,多多关注:码农小胖哥,更多编程干货奉上。
关注公众号:Felordcn 获取更多资讯
个人博客:https://felord.cn