嗯,我的代码没有
else
系列,一个设计模式业务真实使用的golang系列。
前言
本系列主要分享,如何在我们的真实业务场景中使用设计模式。
本系列文章主要采用如下结构:
什么是「XX设计模式」?
什么真实业务场景可以使用「XX设计模式」?
怎么用「XX设计模式」?
本文主要介绍「责任链模式」如何在真实业务场景中使用。
什么是「责任链模式」?
首先把一系列业务按职责划分成不同的对象,接着把这一系列对象构成一个链,然后在这一系列对象中传递请求对象,直到被处理为止。
我们从概念中可以看出责任链模式有如下明显的优势:
按职责划分:解耦
对象链:逻辑清晰
但是有一点直到被处理为止
,代表最终只会被一个实际的业务对象执行了实际的业务逻辑,明显适用的场景并不多。但是除此之外,上面的那两点优势还是让人很心动,所以,为了适用于目前所接触的绝大多数业务场景,把概念进行了简单的调整,如下:
首先把一系列业务按职责划分成不同的对象,接着把这一系列对象构成一个链,直到“链路结束”为止。(结束:异常结束,或链路执行完毕结束)
简单的直到“链路结束”为止
转换可以让我们把责任链模式适用于任何复杂的业务场景。
以下是责任链模式(改)的具体优势:
直观:一眼可观的业务调用过程
无限扩展:可无限扩展的业务逻辑
高度封装:复杂业务代码依然高度封装
极易被修改:复杂业务代码下修改代码只需要专注对应的业务类(结构体)文件即可,以及极易被调整的业务执行顺序
什么真实业务场景可以用「责任链模式(改)」?
满足如下要求的场景:
业务极度复杂的所有场景
任何杂乱无章的业务代码,都可以使用责任链模式(改)去重构、设计。
我们有哪些真实业务场景可以用「责任链模式(改)」呢?
比如电商系统的下单接口,随着业务发展不断的发展,该接口会充斥着各种各样的业务逻辑。
怎么用「责任链模式(改)」?
关于怎么用,完全可以生搬硬套我总结的使用设计模式的四个步骤:
业务梳理
业务流程图
代码建模
代码demo
业务梳理
步骤 | 逻辑 |
---|---|
1 |
参数校验 |
2 | 获取地址信息 |
3 | 地址信息校验 |
4 | 获取购物车数据 |
5 | 获取商品库存信息 |
6 | 商品库存校验 |
7 | 获取优惠信息 |
8 | 获取运费信息 |
9 | 使用优惠信息 |
10 | 扣库存 |
11 | 清理购物车 |
12 | 写订单表 |
13 | 写订单商品表 |
14 | 写订单优惠信息表< |