重学 Java 设计模式:实战桥接模式 (多支付渠道「微信、支付宝」与多支付模式「刷脸、指纹」场景)
作者:小傅哥
博客:https://bugstack.cn - 编写系列原创专题文章
沉淀、分享、成长,让自己和他人都能有所收获!😄
一、前言
为什么你的代码那么多ifelse
同类的业务、同样的功能,怎么就你能写出来那么多ifelse
。很多时候一些刚刚从校园进入企业的萌新,或者一部分从小公司跳槽到大企业的程序员,初次承接业务需求的时候,往往编码还不成熟,经常一杆到底的写需求。初次实现确实很快,但是后期维护和扩展就十分痛苦。因为一段代码的可读性阅读他后期的维护成本也就越高。
设计模式是可以帮助你改善代码
很多时候你写出来的ifelse
都是没有考虑使用设计模式优化,就像;同类服务的不同接口适配包装、同类物料不同组合的建造、多种奖品组合的营销工厂等等。它们都可以让你代码中原本使用if
判断的地方,变成一组组类和面向对象的实现过程。
怎么把设计模式和实际开发结合起来
多从实际场景思考,只找到代码优化的最佳点,不要可以想着设计模式的使用。就像你最开始看设计模式适合,因为没有真实的场景模拟案例,都是一些画圆形、方形,对新人或者理解能力还不到的伙伴来说很不友好。所以即使学了半天 ,但实际使用还是摸不着头脑。
二、开发环境
JDK 1.8
Idea + Maven
涉及工程三个,可以通过关注公众号:bugstack虫洞栈,回复
源码下载
获取(打开获取的链接,找到序号18)
三、桥接模式介绍
桥接模式的主要作用就是通过将抽象部分与实现部分分离,把多种可匹配的使用进行组合。说白了核心实现也就是在A类中含有B类接口,通过构造函数传递B类的实现,这个B类就是设计的桥
。
那么这样的桥接模式,在我们平常的开发中有哪些场景
JDBC多种驱动程序的实现、同品牌类型的台式机和笔记本平板、业务实现中的多类接口同组过滤服务等。这些场景都比较适合使用桥接模式进行实现,因为在一些组合中如果有如果每一个类都实现不同的服务可能会出现笛卡尔积,而使用桥接模式就可以非常简单。
四、案例场景模拟
随着市场的竞争在支付服务行业出现了微信和支付宝还包括一些其他支付服务,但是对于商家来说并不希望改变用户习惯。就像如果我的地摊只能使用微信或者只能使用支付宝付款,那么就会让我顾客伤心,鸡蛋灌饼也卖不动了。
在这个时候就出现了第三方平台,把市面上综合占据市场90%以上的支付服务都集中到自己平台中,再把这样的平台提供给店铺、超市、地摊使用,同时支持人脸、扫描、密码多种方式。
我们这个案例就模拟一个这样的第三方平台来承接各个支付能力,同时使用自家的人脸让用户支付起来更加容易。那么这里就出现了多支付与*多模式*的融合使用,如果给每一个支付都实现一次不同的模式,即使是继承类也需要开发好多。而且随着后面接入了更多的支付服务或者支付方式,就会呈爆炸似的扩展。
所以你现在可以思考一下这样的场景该如何实现?
五、用一坨坨代码实现
产品经理说老板要的需求,要尽快上,kpi你看着弄!
既然你逼我那就别怪我无情,还没有我一个类写不完的需求!反正写完就完事了,拿完绩效也要走了天天逼着写需求,代码越来越乱心疼后面的兄弟3秒。
1. 工程结构
只有一个类里面都是
ifelse
,这个类实现了支付和模式的全部功能。
2. 代码实现
上面的类提供了一个支付服务功能,通过提供的必要字段;
用户ID
、交易ID
、金额
、渠道
、模式
,来控制支付方式。以上的
ifelse
应该是最差的一种写法,即使写ifelse
也是可以优化的方式去写的。
3. 测试验证
3.1 编写测试类
以上分别测试了两种不同的支付类型和支付模式;微信人脸支付、支付宝指纹支付
3.2 测试结果
从测试结果看已经满足了我们的不同支付类型和支付模式的组合,但是这样的代码在后面的维护以及扩展都会变得非常复杂。
六、桥接模式重构代码
接下来使用桥接模式来进行代码优化,也算是一次很小的重构。
从上面的ifelse
方式实现来看,这是两种不同类型的相互组合。那么就可以把支付方式和*支付模式*进行分离通过抽象类依赖实现类的方式进行桥接,通过这样的拆分后支付与模式其实是可以单独使用的,当需要组合时候只需要把模式传递给支付即可。
桥接模式的关键是选择的桥接点拆分,是否可以找到这样类似的相互组合,如果没有就不必要非得使用桥接模式。
1. 工程结构
桥接模式模型结构
左侧
Pay
是一个抽象类,往下是它的两个支付类型实现;微信支付、支付宝支付。右侧
IPayMode
是一个接口,往下是它的两个支付模型;刷脸支付、指纹支付。那么,
支付类型
×支付模型
= 就可以得到相应的组合。
2. 代码实现
2.1 支付类型桥接抽象类
在这个类中定义了支付方式的需要实现的划账接口:
transfer
,以及桥接接口;IPayMode
,并在构造函数中用户方自行选择支付方式。如果没有接触过此类实现,可以重点关注
IPayMode payMode
,这部分是桥接的核心。
2.2 两个支付类型的实现
微信支付
支付宝支付
这里分别模拟了调用第三方的两个支付渠道;微信、支付宝,当然作为支付综合平台可能不只是接了这两个渠道,还会有其很跟多渠道。
另外可以看到在支付的时候分别都调用了风控的接口进行验证,也就是不同模式的支付(
刷脸
、指纹
),都需要过指定的风控,才能保证支付安全。
2.3 定义支付模式接口
任何一个支付模式;刷脸、指纹、密码,都会过不同程度的安全风控,这里定义一个安全校验接口。
2.4 三种支付模式风控(刷脸、指纹、密码)
刷脸
指纹
密码
在这里实现了三种支付模式(刷脸、指纹、密码)的风控校验,在用户选择不同支付类型的时候,则会进行相应的风控拦截以此保障支付安全。
3. 测试验证
3.1 编写测试类
与上面的ifelse实现方式相比,这里的调用方式变得整洁、干净、易使用;
new WxPay(new PayFaceMode())
、new ZfbPay(new PayFingerprintMode())
外部的使用接口的用户不需要关心具体的实现,只按需选择使用即可。
3.2 测试结果
从测试结果看内容是一样的,但是整体的实现方式有了很大的变化。所以有时候不能只看结果,也要看看过程
七、总结
通过模拟微信与支付宝两个支付渠道在不同的支付模式下,
刷脸
、指纹
、密码
,的组合从而体现了桥接模式的在这类场景中的合理运用。简化了代码的开发,给后续的需求迭代增加了很好的扩展性。从桥接模式的实现形式来看满足了单一职责和开闭原则,让每一部分内容都很清晰易于维护和拓展,但如果我们是实现的高内聚的代码,那么就会很复杂。所以在选择重构代码的时候,需要考虑好整体的设计,否则选不到合理的设计模式,将会让代码变得难以开发。
任何一种设计模式的选择和使用都应该遵顼符合场景为主,不要刻意使用。而且统一场景因为业务的复杂从而可能需要使用到多种设计模式的组合,才能将代码设计的更加合理。但这种经验需要从实际的项目中学习经验,并提不断的运用。
八、推荐阅读
版权声明: 本文为 InfoQ 作者【小傅哥】的原创文章。
原文链接:【http://xie.infoq.cn/article/92805e7d19691df4b0dd556c4】。文章转载请联系作者。
评论 (2 条评论)