共计 3709 个字符,预计需要花费 10 分钟才能阅读完成。
个别做业务开发,不太容易有大量应用设计模式的场景。这里总结一下在业务开发中应用较为频繁的设计模式。当然语言为 Java,基于 Spring 框架。
1 责任链模式(Chain of Responsibility Pattern)
对数据流、对象做一系列过滤、校验、解决等操作,该操作通常是有序的。该场景在生活中还是很常见的,如大家常常举例的各种审批流。再如面试,须要通过一面、二面、三面、HR 面等,最终拿下 Offer。这些都属于责任链的场景,
责任链模式个别有 3 个角色:
- Client: 客户端。用来编排处理器,可动态、也可运行时动静生成。相似单链表。
- Handler: 接口或抽象类。约定处理函数名称、参数等。
- ConcreteHandler: 具体处理器。
这种呈现的场景其实挺多,但真正应用的却不是很多。这就要提到责任链的几个毛病:灵便动静既是长处也是毛病,使得程序不够直观,流程不够明了。甚至可能呈现循环援用 (死循环) 的状况。
责任链的编排个别有两种:
- 内部编排:具体处理器,仅依据 Contex 参数进行解决,并将后果回写 Contex。外部不做编排。绝对比拟独立 (纯正) 的逻辑处理单元。
- 外部编排:相似单链表。在执行过程中,依据 Context 参数的处理结果,判断是否须要进行下一步(进入下一个处理器)。绝对内部编排,灵便度略低一些。
1.1 理论业务场景
在用户留资进线场景中,咱们须要依据线索的渠道号、落地页起源、学科等做不同的逻辑解决。但在未失去理论参数前,咱们是不能确定具体要走哪些处理器。一些业务规定(简化):
- 渠道号 (channel) 不能为空
- 某些非凡渠道号,推荐人不能为空
- 某些落地页起源(lpv),偏好语言不能为空
只有全副符合条件的线索,能力理论进入到 CRM 零碎中。
线索 LeadsBO
@Data
@Builder
public class LeadsBO {
// 渠道号
private String channel;
// 推荐人 ID
private Long referrerId;
// 学科 1: 中文 2: 英文
private Integer subject;
// 落地页版本(Landing Page Version)
private String lpv;
// 偏好语言
private String preferenceLanguage;
// 责任链回写
// 数据是否无效
@Builder.Default
private boolean valid = true;
// 异样信息(谬误日志)
private String errMsg;
}
线索过滤器(即 Handler 处理器) Filter
/**
* 线索过滤器
*/
public interface Filter {void process(LeadsBO bo);
}
4 个具体处理器
/**
* 渠道号过滤器
*/
@Component("channel")
public class ChannelFilter implements Filter {
@Override
public void process(LeadsBO bo) {if (StringUtils.isBlank(bo.getChannel())) {bo.setValid(false);
bo.setErrMsg("channel 为空");
}
}
}
/**
* 推荐人过滤
*/
@Component("referrer")
public class ReferrerFilter implements Filter {
private static final Set<String> CHANNELS = Set.of("LP-XX-XX-01", "LP-XX-XX-02");
@Override
public void process(LeadsBO bo) {final String channel = bo.getChannel();
final Long referrerId = bo.getReferrerId();
if (CHANNELS.contains(channel) && Objects.isNull(referrerId)) {bo.setValid(false);
bo.setErrMsg("特定渠道号, 推荐人不能为空");
}
}
}
/**
* 落地页版本号校验
*/
@Component("lpv")
public class LpvFilter implements Filter {
@Override
public void process(LeadsBO bo) {final String lpv = bo.getLpv();
if (StringUtils.isNoneBlank(lpv) && lpv.startsWith("XZ") && StringUtils.isBlank(bo.getPreferenceLanguage())) {bo.setValid(false);
bo.setErrMsg("偏好语言不能为空");
}
}
}
/**
* 学科过滤器
*
*/
@Component("subject")
public class SubjectFilter implements Filter {
@Override
public void process(LeadsBO bo) {final Integer subject = bo.getSubject();
if (Objects.isNull(subject) || (subject != 1 && subject != 2)) {bo.setSubject(1);
}
}
}
能够看到,咱们在定义处理器时,并没有在处理器外部动静指定下一个解决。咱们将处理器的编排放在内部设置,这样更加的灵便一下。借助于 Spring,给具体解决增加别名,不便后续应用。
上面再定义一个线索拦挡服务,其实就是将 Client 的局部逻辑进行封装,使得调用更加简略一些。只须要内部传递参数 (LeadsBO),以及处理器别名的编排序列(List<String>) 即可。
LeadsFilterService
/**
* 线索拦截器
*/
public interface LeadsFilterService {void filter(LeadsBO bo, List<String> filterChain);
}
/**
* 线索拦截器
*/
@Slf4j
@Service
public class LeadsFilterServiceImpl implements LeadsFilterService, ApplicationContextAware {
private ApplicationContext appCtx;
@Override
public void filter(LeadsBO bo, List<String> filterChain) {for (String fc : filterChain) {final Filter filter = appCtx.getBean(fc, Filter.class);
filter.process(bo);
if (!bo.isValid()) {log.error("[线索拦挡] 数据异样 errMsg=>{}", bo.getErrMsg());
return;
}
}
}
@Override
public void setApplicationContext(ApplicationContext ctx) throws BeansException {appCtx = ctx;}
}
借助 ApplicationContextAware
拿到 Spring 容器上下文,不便依据别名获取 Bean 对象。
1.2 单测
@SpringBootTest
class LeadsFilterServiceTest {
@Autowired
LeadsFilterService service;
@Test
void testChannel() {final LeadsBO bo = LeadsBO.builder().build();
service.filter(bo, List.of("channel", "subject", "lpv", "referrer"));
assertFalse(bo.isValid());
}
@Test
void testReferrer() {final LeadsBO bo = LeadsBO.builder().channel("LP-XX-XX-01").referrerId(123L).build();
service.filter(bo, List.of("channel", "subject", "lpv", "referrer"));
assertEquals(1, bo.getSubject());
assertTrue(bo.isValid());
}
}
2 思考
责任链模式能带来什么?
- 高内聚低耦合,将具体业务逻辑稀释到具体处理器。
- 易于拓展,有新逻辑,间接继承、或实现处理器即可。
- 若有多种场景,须要不同的编排时,可高效复用这些处理器。
跟策略模式有啥区别?
- 策略模式个别只会由某个具体的策略去解决,其余策略不会参加。
- 责任链模式则是每个处理器都有可能取得解决权限。重点在于链式。
有啥注意事项呢?
- 防止滥用。但在适合的场景要大胆去应用。
- 肯定要避免出现循环援用的状况。
封面图起源:https://refactoring.guru/desi…