最近在作的事情是为语法规则制定相应的数据结构,并将二者集成起来。这个环节的工作在难度上来说并不是太
大,但是复杂度却不算小。因为涉及到的语法规则非常多,相关的数据结构也数量庞大,粗略统计了一下,现在为
语法数据结构引入的类已经有60多个了,涉及到的代码量也有5k行之上,虽然每个类的描述并不复杂,但这么多类,
之间难免有相互包含,继承的关系,在设计过程中要将这些类的关系,描述记在脑袋里,以考虑进一步的设计,优
化,还是一件颇费脑力的事情。这5K多行代码是在大约不到三周的时间完成编写的,乍听起来似乎有点吓人,实则
不然。因为这段时间,自己的主要工作是完成从语法规则层面到对象层面的一个浅层次的映射,这层映射涉及到的
抽象和变换并不太多,更多的是平铺直叙的转换工作,对于一个编程熟手来说,干起这样的工作是驾轻就熟的事
情,所以有着较高的代码产出量也不是什么新鲜事。 (其实我个人的想法,完成这层映射工作最理想的方式是引入一
个中间的转换工具,指定了一定的描述规则以后,直接利用该工具就可以从语法规则生成相应的类体系,但是基于
yacc并没有成熟的类似工具,自己开发一个这样的工具在项目资源上来看又不太现实,所以还是只能手动来完成语
法规则到语法数据映射工作了)。
稍微把问题引开一点来说, 软件设计人员的目标职能是在现实问题和执行具体操作的目标机器域之间搭建起一
座桥梁,通过程序的建模和抽象,最终让目标机器可以理解,分析并给出现实问题的解决办法。为了达到这
个目的,程序员既可以选择一步到位,直接将现实问题映射成目标机器可以理解的方式,也可以选择通过多级层次
的抽象,将问题的难度逐层分解,最终映射到目标机器域。前者的典型例子是用机器语言编程,后者的典型例子就
是用高级语言编程了。而基于高级语言,在问题建模以及软件的系统架构上我们还可以进一步采用类似的手段: 先
以较小的代价将原始问题映射到一个中间层次上,在这层映射中,会完成部分抽象,建模的工作,以缩减原始问题
与目标机器域的差异。然后基于这个中间层次,还可以再引入更多个中间层次,逐层缩减问题与目标机器域的差
异,最终,将原始问题映射到目标机器域。
采用多层映射的方式的优点之一是,这样有利于减少理解系统局部模块的代价和成本。对于一个大型系统,这样会
有利于系统的扩展和维护。当然,引入中间层次也会在性能上带来相当的影响,这就需要设计人员根据具体的问题
需求来进行权衡了。
大,但是复杂度却不算小。因为涉及到的语法规则非常多,相关的数据结构也数量庞大,粗略统计了一下,现在为
语法数据结构引入的类已经有60多个了,涉及到的代码量也有5k行之上,虽然每个类的描述并不复杂,但这么多类,
之间难免有相互包含,继承的关系,在设计过程中要将这些类的关系,描述记在脑袋里,以考虑进一步的设计,优
化,还是一件颇费脑力的事情。这5K多行代码是在大约不到三周的时间完成编写的,乍听起来似乎有点吓人,实则
不然。因为这段时间,自己的主要工作是完成从语法规则层面到对象层面的一个浅层次的映射,这层映射涉及到的
抽象和变换并不太多,更多的是平铺直叙的转换工作,对于一个编程熟手来说,干起这样的工作是驾轻就熟的事
情,所以有着较高的代码产出量也不是什么新鲜事。 (其实我个人的想法,完成这层映射工作最理想的方式是引入一
个中间的转换工具,指定了一定的描述规则以后,直接利用该工具就可以从语法规则生成相应的类体系,但是基于
yacc并没有成熟的类似工具,自己开发一个这样的工具在项目资源上来看又不太现实,所以还是只能手动来完成语
法规则到语法数据映射工作了)。
稍微把问题引开一点来说, 软件设计人员的目标职能是在现实问题和执行具体操作的目标机器域之间搭建起一
座桥梁,通过程序的建模和抽象,最终让目标机器可以理解,分析并给出现实问题的解决办法。为了达到这
个目的,程序员既可以选择一步到位,直接将现实问题映射成目标机器可以理解的方式,也可以选择通过多级层次
的抽象,将问题的难度逐层分解,最终映射到目标机器域。前者的典型例子是用机器语言编程,后者的典型例子就
是用高级语言编程了。而基于高级语言,在问题建模以及软件的系统架构上我们还可以进一步采用类似的手段: 先
以较小的代价将原始问题映射到一个中间层次上,在这层映射中,会完成部分抽象,建模的工作,以缩减原始问题
与目标机器域的差异。然后基于这个中间层次,还可以再引入更多个中间层次,逐层缩减问题与目标机器域的差
异,最终,将原始问题映射到目标机器域。
采用多层映射的方式的优点之一是,这样有利于减少理解系统局部模块的代价和成本。对于一个大型系统,这样会
有利于系统的扩展和维护。当然,引入中间层次也会在性能上带来相当的影响,这就需要设计人员根据具体的问题
需求来进行权衡了。