一、什么是DSL

DSL是(Domain Specified Language)的简称,中文含义为:领域专用语言。
设计者通过特定的语义,描述一些在特定的应用场景中出现的东西。

二、为什么要使用DSL

设计并使用DSL的优势在于:在解决特定问题时,有更简洁、更强大的语义表达能力。可以使用更少的代码(或配置)来描述问题,开发效率高。

我们在日常工作中,往往会在大量重复性的工作上浪费大量时间。针对这种共性很强的工作,我们设计一个具有通用性和简洁性的描述性语言,可以减轻我们的工作负担,也可以使项目代码更简洁易读。

三、分析业务需求

在公司内部系统开发中,有一个这样的需求:

需要设计一个序列号生成器,它能放在不同模块代码中,根据不同模块的序列号生成规则生成序列号。

通过分析生成规则,发现序列号生成器需要包含的功能有:

1. 在不同业务模块中生成的模块CODE不一样
2. 需要包含当前日期。但生成的日期格式每个模块可能会不一样。(有的是yyyy-MM-dd,有的是yyyyMMdd等)
3. 需要生成流水号。流水号各个模块需要生成的位数可能不一样,有的需要定长4位,有的需要定长3位。位数不足的有的需要左补0(或者左补其他符号)

四、DSL设计

通过上述的需求分析,我们不难看出:

  1. 各个业务模块的序列号生成策略有一定的共性:比如都可能包含:日期、流水号等
  2. 序列号生成策略中的变量仅有:模块编码、日期、流水号这三项,且业务模块对于流水号的需求仅定长不同

综上所述,便有了2种解决思路:

  1. 设计一个序列号生成工厂组件,提供:模块编码、日期、流水号等生成策略选项,由开发人员在实际开发过程中自己调用相关方法,按需使用。
  2. 考虑到每个模块都对应一个唯一的模块编码(模块编码要有,但是可以不作为生成序列号的一部分被显示),因此可以将业务模块和对应的模块编码相绑定。然后再利用注解,在对应的模块编码上指定相应的生成策略。

第一种“手动指定策略”的思路我们先不详细说。这里来详细说说第二种思路。

  1. 先将各个业务模块对应的模块编码梳理出来,整理成一个配置类
  2. 在配置类中的模块编码上,使用注解指定该模块对应的序列号生成规则
  3. 打算使用类似于EL表达式中取值的方式(即:类似于:$的方式)(注:后续代码中为了方便,直接用了{}的方式来取值,就没有写$了)来实时计算并填充数据
  4. 将计算出来的序列号返回

因为在业务需求中只有4个变量,所以我们首先得给那4个变量起个名字:
例如:

  • 模块编码可以使用: $来表示
  • 日期可以使用:$来表示
    等等...

五、详细代码设计

  • 首先准备一个配置类,将梳理好的模块编码都放进去
    image.png

  • 使用自定义注解指定序列号生成策略
    image.png

如上图所示,电脑前有新的同学肯定已经发现了:里面还内嵌了一个@Appender注解。啥是@Appender注解?
@Appender注解定义长这样:
image.png
这是因为考虑到后期的代码扩展性,我将流水号生成的策略(占几位,补什么符号等)抽离出来,使用@Appender注解可以起到灵活配置的作用。

  • 写一个脚本解析器,用于解析注解中的序列号生成策略
  1. 首先读取注解内容
    image.png

  2. 计算或获取实际内容,然后替换掉生成策略脚本中对应的变量占位符
    (注:为了精细化控制日期显示格式,所以在代码中用了多种日期格式变量)
    image.png

字符替换方法详情:
image.png

image.png

六、总结

上面只是简单地谈一谈一种基于自定义DSL,结合注解形式来写一个序列号生成器地思路。还有很多细枝末节的东西没有说到,例如:

  • 如何保证每天生成的流水号从1开始顺序累加? --redis或其他分布式锁机制
  • 如何用最短代码将多个模块共用同一套生成策略?
  • 如何同时集成“自动生成”和“手动生成”两种方式?

如果展开说那又可以水一篇博文了,这篇文章主要说一下思路,也算是给自己做一个经验累积~

知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议

摸鱼癌晚期患者