作者:哒Dayling玲 | 来源:互联网 | 2023-06-18 08:01
原始文章首发于个人博客
DSL是(Domain Specified Language)的简称,中文含义为:领域专用语言。
设计者通过特定的语义,描述一些在特定的应用场景中出现的东西。
二、为什么要使用DSL
设计并使用DSL的优势在于:在解决特定问题时,有更简洁、更强大的语义表达能力。可以使用更少的代码(或配置)来描述问题,开发效率高。
我们在日常工作中,往往会在大量重复性的工作上浪费大量时间。针对这种共性很强的工作,我们设计一个具有通用性和简洁性的描述性语言,可以减轻我们的工作负担,也可以使项目代码更简洁易读。
三、分析业务需求
在公司内部系统开发中,有一个这样的需求:
需要设计一个序列号生成器,它能放在不同模块代码中,根据不同模块的序列号生成规则生成序列号。
通过分析生成规则,发现序列号生成器需要包含的功能有:
1. 在不同业务模块中生成的模块CODE不一样
2. 需要包含当前日期。但生成的日期格式每个模块可能会不一样。(有的是yyyy-MM-dd,有的是yyyyMMdd等)
3. 需要生成流水号。流水号各个模块需要生成的位数可能不一样,有的需要定长4位,有的需要定长3位。位数不足的有的需要左补0(或者左补其他符号)
四、DSL设计
通过上述的需求分析,我们不难看出:
- 各个业务模块的序列号生成策略有一定的共性:比如都可能包含:日期、流水号等
- 序列号生成策略中的变量仅有:模块编码、日期、流水号这三项,且业务模块对于流水号的需求仅定长不同
综上所述,便有了2种解决思路:
- 设计一个序列号生成工厂组件,提供:模块编码、日期、流水号等生成策略选项,由开发人员在实际开发过程中自己调用相关方法,按需使用。
- 考虑到每个模块都对应一个唯一的模块编码(模块编码要有,但是可以不作为生成序列号的一部分被显示),因此可以将业务模块和对应的模块编码相绑定。然后再利用注解,在对应的模块编码上指定相应的生成策略。
第一种“手动指定策略”的思路我们先不详细说。这里来详细说说第二种思路。
- 先将各个业务模块对应的模块编码梳理出来,整理成一个配置类
- 在配置类中的模块编码上,使用注解指定该模块对应的序列号生成规则
- 打算使用类似于EL表达式中取值的方式(即:类似于:xxx的方式)(注:后续代码中为了方便,直接用了的方式来取值,就没有写{xxx}的方式)(注:后续代码中为了方便,直接用了{}的方式来取值,就没有写xxx的方式)(注:后续代码中为了方便,直接用了的方式来取值,就没有写了)来实时计算并填充数据
- 将计算出来的序列号返回
因为在业务需求中只有4个变量,所以我们首先得给那4个变量起个名字:
例如:
- 模块编码可以使用: ${module_code}来表示
- 日期可以使用:${date}来表示
等等…
五、详细代码设计
- 首先准备一个配置类,将梳理好的模块编码都放进去
- 使用自定义注解指定序列号生成策略
如上图所示,电脑前有新的同学肯定已经发现了:里面还内嵌了一个@Appender注解。啥是@Appender注解?
@Appender注解定义长这样:
这是因为考虑到后期的代码扩展性,我将流水号生成的策略(占几位,补什么符号等)抽离出来,使用@Appender注解可以起到灵活配置的作用。
- 写一个脚本解析器,用于解析注解中的序列号生成策略
-
首先读取注解内容
-
计算或获取实际内容,然后替换掉生成策略脚本中对应的变量占位符
(注:为了精细化控制日期显示格式,所以在代码中用了多种日期格式变量)
字符替换方法详情:
六、总结
上面只是简单地谈一谈一种基于自定义DSL,结合注解形式来写一个序列号生成器地思路。还有很多细枝末节的东西没有说到,例如:
- 如何保证每天生成的流水号从1开始顺序累加? --redis或其他分布式锁机制
- 如何用最短代码将多个模块共用同一套生成策略?
- 如何同时集成“自动生成”和“手动生成”两种方式?
如果展开说那又可以水一篇博文了,这篇文章主要说一下思路,也算是给自己做一个经验累积~