链式调用 | 我的代码没有else

嗯，我的代码没有else系列，一个设计模式业务真实使用的golang系列。

前言

本系列主要分享，如何在我们的真实业务场景中使用设计模式。

本系列文章主要采用如下结构：

• 什么是「XX设计模式」？

• 什么真实业务场景可以使用「XX设计模式」？

• 怎么用「XX设计模式」？

本文主要介绍「责任链模式」如何在真实业务场景中使用。

什么是「责任链模式」？

首先把一系列业务按职责划分成不同的对象，接着把这一系列对象构成一个链，然后在这一系列对象中传递请求对象，直到被处理为止。

我们从概念中可以看出责任链模式有如下明显的优势：

• 按职责划分：解耦

• 对象链：逻辑清晰

但是有一点直到被处理为止，代表最终只会被一个实际的业务对象执行了实际的业务逻辑，明显适用的场景并不多。但是除此之外，上面的那两点优势还是让人很心动，所以，为了适用于目前所接触的绝大多数业务场景，把概念进行了简单的调整，如下：

首先把一系列业务按职责划分成不同的对象，接着把这一系列对象构成一个链，直到“链路结束”为止。(结束：异常结束，或链路执行完毕结束)

简单的直到“链路结束”为止转换可以让我们把责任链模式适用于任何复杂的业务场景。

以下是责任链模式(改)的具体优势：

• 直观：一眼可观的业务调用过程

• 无限扩展：可无限扩展的业务逻辑

• 高度封装：复杂业务代码依然高度封装

• 极易被修改：复杂业务代码下修改代码只需要专注对应的业务类(结构体)文件即可，以及极易被调整的业务执行顺序

什么真实业务场景可以用「责任链模式(改)」？

满足如下要求的场景:

业务极度复杂的所有场景

任何杂乱无章的业务代码，都可以使用责任链模式(改)去重构、设计。

我们有哪些真实业务场景可以用「责任链模式(改)」呢？

比如电商系统的下单接口，随着业务发展不断的发展，该接口会充斥着各种各样的业务逻辑。

怎么用「责任链模式(改)」？

关于怎么用，完全可以生搬硬套我总结的使用设计模式的四个步骤：

• 业务梳理

• 业务流程图

• 代码建模

• 代码demo

业务梳理

步骤	逻辑
1	参数校验
2	获取地址信息
3	地址信息校验
4	获取购物车数据
5	获取商品库存信息
6	商品库存校验
7	获取优惠信息
8	获取运费信息
9	使用优惠信息
10	扣库存
11	清理购物车
12	写订单表
13	写订单商品表
14	写订单优惠信息表<