引言

项目中用到了一些好的设计模式，分享出来。

责任链设计模式+工厂设计模式

使用场景

抽奖前规则校验

功能实现

1.创建责任链接口和抽象类

2.创建责任链实体

目前创建了三个责任链 ，分别是黑名单责任链 权重范围责任链 以及默认抽奖责任链

3.创建责任链构造工厂

工厂类，负责根据策略ID构建责任链，并缓存已构建的责任链。

工厂类的流程图：

使用

组合设计模式+工厂设计模式

使用场景

在抽奖中与后规则过滤使用

对于抽奖中到抽奖后的规则，它是一个非多分支情况的规则过滤。单独的责任链是不能满足的，如果是拆分开抽奖中规则和抽奖后规则分阶段处理，中间单独写逻辑处理库存操作。那么是可以实现的。但这样的方式始终不够优雅，配置化的内容较低，后续的规则开发仍需要在代码上改造。所以这里使用组合模式的决策树模型。

功能实现

规则树模型

• RuleTreeVO 决策树的树根信息，标记出最开始从哪个节点执行「treeRootRuleNode」。

• RuleTreeNodeVO 决策树的节点，这些节点可以组合出任意需要的规则树。

• RuleTreeNodeLineVO 决策树节点连线，用于标识出怎么从一个节点到下一个节点。

规则节点

执行引擎

执行引擎呢，就是负责构建二叉树的调用关系的

执行引擎构建工厂

由决策树工厂管理规则节点的注入和决策树引擎的创建。在使用的时候，可以通过 openLogicTree 方法获取执行器。执行器提供了规则的执行操作。

模板设计模式

使用场景

在进行抽奖方法时，串联所有的抽奖过滤。

功能实现

定义AbstractRaffleStrategy模板类和performRaffle 模板方法

定义raffleLogicChain 和 raffleLogicTree 抽象方法，由子类实现具体的逻辑

子类实现其中的方法

策略设计模式

使用场景

在我们发放奖品的时候，每一种奖品他的发放策略都是一种不同的方法，如果我们使用 if -else 进行判断，这样的硬编码是不美的，我们就此可以使用策略设计模式就行改善，提高代码的可扩展性。

功能实现

奖品是有多种类型的实现的，这些实现可以定义为策略。而策略的唯一标识就是奖品表中的 award_key 值，这个值可以作为 bean 对象的名称。那么在拿到奖品ID，反查到奖品Key的时候，就可以获得到对应的 Bean 对象，以此方式来屏蔽 if···else 的判断使用。

就比如上面这个 每一个 award_key 不就是一个 方法策略么

我们实现每一种策略。

主要目的就是计算下积分的值和发奖更新奖品记录，写入用户积分账户。

我们在创建分发奖品的方法，根据奖品id 查询奖品的配置 根据他的 award_key 找到具体的策略，进行执行。