搜狗站长工具平台,photoshop正版软件多少钱,app需要建网站吗,下载源代码的网站引言
责任链模式是一种行为设计模式#xff0c;它允许你将请求沿着处理者链进行传递#xff0c;直到有一个处理者处理请求。在实际应用中#xff0c;责任链模式常用于解耦发送者和接收者#xff0c;使得请求可以按照一定的规则被多个处理者依次处理。
首先#xff0c;本…引言
责任链模式是一种行为设计模式它允许你将请求沿着处理者链进行传递直到有一个处理者处理请求。在实际应用中责任链模式常用于解耦发送者和接收者使得请求可以按照一定的规则被多个处理者依次处理。
首先本文会通过一个实例去讲解SpringBoot使用责任链模式以及自定义注解优雅的实现一个功能。我们现在有如下图一样的一个创建订单的业务流程处理我们选择使用责任链模式去实现。 我们分析下流程发现从条件x开始就分为了两条业务线我们定义走业务节点A的叫规则A走业务节点B的叫规则B。这样就形成了两条业务链路 那我就开始使用自定义注解定义规则A以及规则B。
规则注解
定义RuleA标识处理规则A的节点
Qualifier
Target({ElementType.METHOD, ElementType.TYPE})
Retention(RetentionPolicy.RUNTIME)
public interface RuleA {
}定义RuleB标识处理规则B的节点
Qualifier
Target({ElementType.METHOD, ElementType.TYPE})
Retention(RetentionPolicy.RUNTIME)
public interface RuleB {
}在Spring框架中Qualifier注解用于指定要注入的具体bean的名称。当一个接口或抽象类有多个实现类时通过Qualifier注解可以明确告诉Spring框架要注入哪一个实现类。
自定义注解与Qualifier结合使用的含义在于你可以通过自定义注解为特定的实现类分组并在使用Qualifier时引用这个自定义注解。这样做的主要目的是提高代码的可读性和可维护性使得注入的意图更加清晰。
业务处理
各业务节点处理的数据是同一份处理方法是一个只是处理的业务不同。所以我们定义一个业务处理点的接口让各业务节点去实现业务处理接口。
public interface INodeComponent{ /**
* 定义所有数据处理节点的接口
* param orderContext 数据上下文
* param orderParam 数据处理入参参数
*/ void handleData(OrderContext orderContext, OrderParam orderParam);
}然后我们实现业务处理接口 我们定义在规则A流程中执行的节点都是用注解RuleA去标记如下
Slf4j
Component
RuleA
Order(1)
public class ANodeComponent implements INodeComponent {Override
public void handleData(OrderContext orderContext, OrderParam orderParam) { log.info(RuleA流程执行处理业务节点A); final ListString executeRuleList Optional.ofNullable(orderContext.getExecuteRuleList()).orElse(new ArrayList()); executeRuleList.add(ANodeComponent); orderContext.setExecuteRuleList(executeRuleList); // 不同类型订单订单号不同可在节点中个处理orderContext.setOrderId(TOC11111);}
}Slf4j
Component
RuleA
RuleB
Order(10)
public class CNodeComponent implements INodeComponent {// 省略具体的业务处理逻辑
}Slf4j
Component
RuleA
Order(20)
public class DNodeComponent implements INodeComponent {// 省略具体的业务处理逻辑
} Slf4j
Component
RuleA
Order(30)
public class FNodeComponent implements INodeComponent {// 省略具体的业务处理逻辑
}Slf4j
Component
RuleA
RuleB
Order(40)
public class HNodeComponent implements INodeComponent {// 省略具体的业务处理逻辑
}我们定义在规则B流程中执行的节点都是用注解RuleB去标记如下
Slf4j
Component
RuleB
Order(1)
public class BNodeComponent implements INodeComponent {log.info(RuleB流程执行处理业务节点B); final ListString executeRuleList Optional.ofNullable(orderContext.getExecuteRuleList()).orElse(new ArrayList()); executeRuleList.add(BNodeComponent);orderContext.setExecuteRuleList(executeRuleList); orderContext.setOrderId(TOB11111);
}Slf4j
Component
RuleA
RuleB
Order(10)
public class CNodeComponent implements INodeComponent {// 省略具体的业务处理逻辑
}Slf4j
Component
RuleB
Order(20)
public class ENodeComponent implements INodeComponent {// 省略具体的业务处理逻辑
}Slf4j
Component
RuleA
RuleB
Order(40)
public class HNodeComponent implements INodeComponent {// 省略具体的业务处理逻辑
}可以看到如果规则A和规则B都需要执行的业务用了RuleA和RuleB去标记。同时我们使用Order注解定义NodeComponent的注入顺序值越小越先注入。 基于Order定义NodeComponent的注入顺序不是那么的友好最好的方式是与规则注解耦合即一个规则下定义注入顺序 规则处理器
我们在定义条件X节点对应的针对处理规则A和规则B的处理器。 同理因规则A以及规则B处理数据的数据是同一份方法也是同一个所以我们还是定义一个处理器超类
Slf4j
public abstract class NodeHandler { /**
* 处理校验订单以及创建订单信息
* param requestVO 订单创建入参
* return 订单DO实体类
*/
public abstract OrderDO handleOrder(OrderCreateRequestVO requestVO); /**
* 执行业务处理链路
* param requestVO 订单创建入参
* param nodeComponentList 业务处理节点
* return
*/
protected OrderDO executeChain(OrderCreateRequestVO requestVO, List? extends INodeComponent nodeComponentList){final OrderParam orderParam this.buildOrderParam(requestVO); final OrderContext orderContext OrderContext.builder().build(); for (INodeComponent nodeComponent : nodeComponentList){ // 此处进行业务处理节点的调用nodeComponent.handleData(orderContext, orderParam); } log.info(执行的链路{}, String.join(,, Optional.ofNullable(orderContext.getExecuteRuleList()).orElse(new ArrayList()))); return this.buildOrderDO(orderContext);
}我们的超类对外提供统一的业务处理接口方法同时对业务处理节点的调用进行处理的管理对于规则处理者来说他只需要实现handlerOrder的方法。以下是规则处理器的实现代码
Slf4j
Component(ruleA)
public class RuleAHandler extends NodeHandler { RuleA
Autowired
private List? extends INodeComponent nodeComponents; /** * 处理校验订单以及创建订单信息 * * param requestVO 订单创建入参 * return 订单DO实体类 */ Override public OrderDO handleOrder(OrderCreateRequestVO requestVO) { return super.executeChain(requestVO, nodeComponents); }
}Slf4j
Component(ruleB)
public class RuleBHandler extends NodeHandler { RuleB Autowired private List? extends INodeComponent nodeComponents; /** * 处理校验订单以及创建订单信息 * * param requestVO 订单创建入参 * return 订单DO实体类 */ Override public OrderDO handleOrder(OrderCreateRequestVO requestVO) { return super.executeChain(requestVO, nodeComponents); }
}订单处理器
最后我们在创建一个订单处理器为业务代码中提供服务接口。 先创建一个订单类型的枚举枚举中定义使用哪个规则处理器。
AllArgsConstructor
public enum OrderHandlerEnum { TO_C(1,ruleA), TO_B(2, ruleB); public final Integer orderType; public final String ruleHandler; public static String getRuleHandler(Integer orderType){ return Arrays.stream(OrderHandlerEnum.values()).filter(e - Objects.equals(e.orderType, orderType)).findFirst() .orElse(OrderHandlerEnum.TO_C).ruleHandler; }
}然后我们就可以定义一个订单处理器了处理中决定调用那个规则处理器去执行规则。
Slf4j
Component
public class OrderFactory { Autowired private MapString, NodeHandler nodeHandlerMap; /** * 创建订单 * param requestVO 订单参数 * return 订单实体DO */ public OrderDO createOrder(OrderCreateRequestVO requestVO){ final Integer orderType requestVO.getOrderType(); // 获取node规则执行器名称 final String ruleHandler OrderHandlerEnum.getRuleHandler(orderType); // 获取node规则执行器 final NodeHandler nodeHandler nodeHandlerMap.get(ruleHandler); if (nodeHandler null){ // 异常 throw new RuntimeException(); } return nodeHandler.handleOrder(requestVO); }
}测试
我们编写测试类看一下效果
SpringBootTest
public class SpringbootCodeApplicationTests { Autowired private OrderFactory orderFactory; Test void testOrderCreate() { final OrderCreateRequestVO requestVO new OrderCreateRequestVO(); requestVO.setOrderNo(11111); requestVO.setOrderType(OrderHandlerEnum.TO_C.orderType); requestVO.setUserId(coderacademy); requestVO.setUserName(码农Academy); final OrderDO orderDO orderFactory.createOrder(requestVO); System.out.println(orderDO.getOrderId()); }
}
执行结果日志如下 执行结果是我们想要的。
通过采用责任链模式结合Spring Boot的优化方案我们实现了一种高度解耦的业务逻辑处理方式。其中的主要优势在于我们成功地将各个业务节点的处理逻辑进行解耦使得每个节点能够独立演进降低了代码的耦合性。
其中的最大优势体现在替换或新增业务节点处理规则时的灵活性。若需替换某一节点的处理规则只需实现新的INodeComponent并标记相应的规则注解系统将自动将其纳入责任链中。这意味着我们能够以最小的改动实现业务逻辑的变更而无需涉及其他节点。
进一步地若新增一条处理规则只需定义新的规则注解如RuleC并实现相应的INodeComponent接口定义规则C下各节点的处理逻辑。然后创建对应的规则C处理器即可系统将自动将其整合到责任链中。这种设计允许我们以一种清晰、简便的方式进行代码扩展同时使得代码接口清晰易懂为后续维护和升级提供了便利。这种设计理念在面对日益变化的业务规则时具有显著的适应性和可维护性。
上述示例中我们也使用了表驱动策略模式工厂模式以及枚举等方式具体请参考我另一篇的文章代码整洁之道一之优化if-else的8种方案
总结
通过使用责任链模式我们可以更优雅地组织和扩展业务逻辑。在Spring Boot中结合自定义注解和Qualifier注解以及构造函数注入可以实现更清晰、可读性更强的代码。通过控制处理者的顺序我们可以确保责任链的执行顺序符合业务需求。
责任链模式的优雅实践使得我们的代码更具可维护性更容易应对业务的变化。在设计和实现中要根据实际业务场景的需要进行灵活调整以达到最佳的解耦和可扩展性。
有的小伙伴可能也会发现我们的类定义为NodeComponent很熟悉是的此类名参考一个规则引擎开源项目LiteFlow我们下一期将会使用LiteFolw改造这个案例由此打开学习LiteFlow的篇章需要了解的小伙伴们注意点关注哦。。。。
本文已收录于我的个人博客码农Academy的博客专注分享Java技术干货包括Java基础、Spring Boot、Spring Cloud、Mysql、Redis、Elasticsearch、中间件、架构设计、面试题、程序员攻略等
