最近和后端同学交流米奇妙妙代码,发现了一种很邪魅(我个人觉得)的策略模式代码,来给大伙评评。
策略模式我们都知道简单来说就是将策略罗列为字典,然后将状态作为 key 值传入字典执行对应的函数体,或者用 switch case 的方式去实现策略模式。
但我看到的是这样的代码
async function run(query) {
await planA(query);
await planB(query);
await planC(query);
await planD(query);
await planE(query);
}
async function planA(query) {
if (query.type !== 'A') return
... planA 代码执行体
}
async function planB (query) {
if (query.type !== 'B') return
... planB 代码执行体
}
PlanCDE 如法炮制
对没错,这哥们将本来前置的判断后置放进了函数体里,变成了反向的取反型策略模式,换来的是简洁的函数主体。瞬间让我的大脑拧成麻花,居然,还可以这么写啊。
接口幂等该如何设计和实现
在程序开发的过程中是否遇到如下的问题:
同一件商品手速很快多点击了几次,在后台生成了两笔订单。
同一笔订单点了由于网络卡顿,点了两次支付,结果发现重复支付了。
微服务架构下应用间通过RPC调用失败,进入重试机制,导致一个请求提交多次。
黑客利用充值抓包到的数据,进行多次调用充值、评论、访问,造成数据的异常。
这些问题均可以通过接口幂等性设计来解决。幂等性意味着同一个请求无论被重复执行多少次,都能产生相同的结果,不会导致重复的操作或不一致的数据状态。
公众号:
mp.weixin.qq.com
CSDN:
blog.csdn.net
掘金:
juejin.cn
知乎:
zhuanlan.zhihu.com
简书:
www.jianshu.com
cnblog:
www.cnblogs.com
github:
r0ad.github.io
#新人报到#
在程序开发的过程中是否遇到如下的问题:
同一件商品手速很快多点击了几次,在后台生成了两笔订单。
同一笔订单点了由于网络卡顿,点了两次支付,结果发现重复支付了。
微服务架构下应用间通过RPC调用失败,进入重试机制,导致一个请求提交多次。
黑客利用充值抓包到的数据,进行多次调用充值、评论、访问,造成数据的异常。
这些问题均可以通过接口幂等性设计来解决。幂等性意味着同一个请求无论被重复执行多少次,都能产生相同的结果,不会导致重复的操作或不一致的数据状态。
公众号:
CSDN:
掘金:
知乎:
简书:
cnblog:
github:
#新人报到#
展开
评论
点赞