本文由 简悦 SimpRead 转码, 原文地址 blog.csdn.net
举个栗子
我任职于一家小电商,我这边的下单接口有如下的业务流程:
光看这流程图,就可以感知复杂。我在重构时就利用了设计模式,加强了它的扩展性、可读性。
模版方法
例如优惠券校验这个一小部分,伪代码如下:
if 是否使用优惠券 then
优惠券校验
else if
//do nothing
endif
我第一个想到的就是模版方法。
将不变的部分放在父类,由不同的子类去实现变化的部分。
这里变的部分是校验逻辑,不变的是 if-else。
父类 AbstractOrderSubmitTransactionTemplate 如下:
public abstract class AbstractOrderSubmitTransactionTemplate implements OrderSubmitTransactionTemplate{
protected abstract boolean test(Context context);
protected abstract void doValidate(Context context);
protected abstract void doPrepare(Context context);
protected abstract void doCommit(Context context);
protected abstract void doRollback(Context context);
@Override
public void validate(Context context) {
if(test(context)){
//日志记录
doValidate(context);
//日志记录
}
}
@Override
public final void prepare(Context context) {
if(test(context)){
//日志记录
doPrepare(context);
//日志记录
}
}
@Override
public final void commit(Context context) {
if(test(context)){
//日志记录
doCommit(context);
//日志记录
}
}
@Override
public final void rollback(Context context) {
if(test(context)){
//日志记录
doRollback(context);
//日志记录
}
}
}
根据接口分离原则,定义供调用者调用的接口 OrderSubmitTransactionTemplate
public interface OrderSubmitTransactionTemplate{
void validate(Context context);
void prepare(Context context);
void commit(Context context);
void rollback(Context context);
}
举例,用于处理优惠券的子类 CouponTransactionTemplate 实现:
public class CouponTransactionTemplate extends AbstractOrderSubmitTransactionTemplate{
@Override
public boolean test(Context context) {
return context.isUseCoupon();
}
@Override
protected void doValidate(Context context) {
//优惠券校验
}
@Override
protected void doPrepare(Context context) {
//优惠券预扣减
}
@Override
protected void doCommit(Context context) {
//优惠券扣减提交
}
@Override
protected void doRollback(Context context) {
//优惠券扣减回滚
}
}
基于模版方法的改造就完成了,我的业务代码也就变成了下面这样:
public void submit(Context context){
//校验
stockTransactionTemplate.validate(context);
couponTransactionTemplate.validate(context);
activityTransactionTemplate.validate(context);
//预扣减
stockTransactionTemplate.prepare(context);
couponTransactionTemplate.prepare(context);
activityTransactionTemplate.prepare(context);
try{
//下单流程
//确认扣减
stockTransactionTemplate.commit(context);
couponTransactionTemplate.commit(context);
activityTransactionTemplate.commit(context);
}catch (Exception e){
//回滚扣减
stockTransactionTemplate.rollback(context);
couponTransactionTemplate.rollback(context);
activityTransactionTemplate.rollback(context);
}
}
责任链模式
光使用模版方法改造,其实还不够,只是减少了 if-else,并没有符合开闭原则,也就是说当我需要加入一种全新的优惠券时,又需要改动我下单方法(submit)
所以,我又想到了责任链模式。
调用者将请求传给责任链,具体哪些个对象负责执行,由责任链上的对象自行判断是否处理。
我在 AbstractOrderSubmitTransactionTemplate 类中定义的 test 方法,其实已经可以实现对象自行判断是否处理。所以这里我只要把所有的 AbstractOrderSubmitTransactionTemplate 子类挨个轮询就可以实现责任链模式。
例如校验方法(validate)可以这样实现:
@Autowired
private List<AbstractOrderSubmitTransactionTemplate> transactionTemplates;
public void validate(Context context){
for (AbstractOrderSubmitTransactionTemplate transactionTemplate : transactionTemplates) {
transactionTemplate.validate(context);
}
}
这里可以利用 spring 的 @Autowired 注解,将 AbstractOrderSubmitTransactionTemplate 的子类注入到一个 list 中。
经过改造后,我的业务代码成了这样:
public void submit(Context context){
//校验
validate(context);
//预扣减
prepare(context);
try{
//下单流程
//确认扣减
commit(context);
}catch (Exception e){
//回滚扣减
rollback(context);
}
}
策略模式
假设某一天,随着公司业务扩张,需要根据不同的订单类型,执行不同的下单逻辑。也就是我的下单流程要改,有些订单类型插入 A 库,有些订单类型插入 B 库,有些订单类型可能不插库直接放到其他系统去。
伪代码如下
//校验
//预扣减
//下单流程
if 订单类型为1 then
插入A库
else if 订单类型为2 then
插入B库
else if 订单类型为3 then
调用C系统同步订单
end if
//扣减提交/扣减回滚
校验、预扣减、扣减提交 / 扣减回滚这块和下单流程这块是一对多的关系,所以我这边想到的是利用策略模式去实现这个需求。
业务模块之间是 1 对多的关系,将每个模块封装成策略,组合使用。
下单流程策略接口 OrderSubmitStrategy:
public interface OrderSubmitStrategy{
void submit(Context context);
}
依旧使用模版方法定义了抽象的父类
public abstract class AbstractOrderSubmitStrategy implements OrderSubmitStrategy {
protected abstract void doSubmit(Context context);
public final void submit(Context context){
//日志记录
this.doSubmit(context);
//日志记录
}
}
其中一个子类如下:
public class OrderSubmitV1Strategy extends AbstractOrderSubmitStrategy{
@Override
protected void doSubmit(Context context) {
//v1 下单
}
}
经过改造,我的业务代码变成了这样:
public void submit(Context context,OrderSubmitStrategy orderSubmitStrategy){
//校验
validate(context);
//预扣减
prepare(context);
try{
//下单流程
orderSubmitStrategy.submit(context);
//确认扣减
commit(context);
}catch (Exception e){
//回滚扣减
rollback(context);
}
}
在具体调用时,根据不同策略执行不同的下单逻辑:
@PostMapping("/v1/submit")
public SubmitRes submit(SubmitForm form){
Context context = new Context(form);
orderSubmitBean.submit(context,orderSubmitV1Strategy);
return context.getSubmitRes();
}
@PostMapping("/v2/submit")
public SubmitRes submit(SubmitForm form){
Context context = new Context(form);
orderSubmitBean.submit(context,orderSubmitV2Strategy);
return context.getSubmitRes();
}
观察者模式
下单之后,需要通知其他系统,比如大数据系统。这些通知并不需要保证强一致性,只需要最终一致性,一般我们都利用消息中间件来通知,但是通知多了,发送消息代码的严重影响代码简洁,而且每次有新的消息需要发送都需要改动 submit 方法。
于是,我就想到的观察者模式来实现。
当一个对象被修改时,则会自动通知依赖它的对象
观察者接口:
public static interface OrderSubmitListener{
void handle(Context context);
}
notifyListeners 方法:
@Autowired
private List<OrderSubmitListener> listeners;
void notifyListeners(Context context){
for (OrderSubmitListener listener : listeners) {
listener.handle(context);
}
}
这里可以利用 spring 的 @Autowired 注解,将 OrderSubmitListener 的子类注入到一个 list 中。
改造后代码如下:
public void submit(Context context,OrderSubmitStrategy orderSubmitStrategy){
//校验
validate(context);
//预扣减
prepare(context);
try{
//下单流程
orderSubmitStrategy.submit(context);
//确认扣减
commit(context);
}catch (Exception e){
//回滚扣减
rollback(context);
}
notifyListeners(context);
}
标签:重构,context,流程,submit,public,下单,Context,void
From: https://www.cnblogs.com/xmanblue/p/17011892.html