事实上其的作用与优势还是可以的,因为INI文件格式很容易表示描述性的东西,简单不过了,而且系统又支持对INI文法的支持,即使不支持,你也可以自己写一个出来,之所以选择INI来作为描述层,当时也有很大一部分是因为能力实在有限,对编译文法等一些理论不是很熟悉,应用就更不用说了,其次也是想先用INI文件来表述,到时如果时间充足就换成一个XML脚本描述语言就可以了,后来也就发现INI是一个最好的选择,简单,好用,对于其它人来说也是容易接受的,所以后来就没有作一些改变,一直沿用INI的表示文法。 第二部分是基于描述文本的解析部分,其它这一部分才是系统的核心开发引擎,前一部分是它的一个描述文本,其对描述文本进行解析,没有生成中间代码,直接执行,得到执行完毕的结果。没有太多高深的理论,应该是比较明白,当然现在在写这些文件的时候,就发现,原理比较容易理解,可让根据这些文档去重新实现的时候,就觉得比较难了,我想原理可能有一个吧,就是对这个系统究竟是怎么回事,究竟要作什么没有一个比较清晰的概念,因为我在开始的时候,我也不是很清楚,当然我不是因为想开发这个引擎,而决定开发,而是我做OA系统的时候,想一想,能不能得用它可以帮我在OA系统的开发提高一些效率,仅此而己,所以当OA系统完工的时候,也是这个开发引擎或是开发平台完成的时候,当然这个引擎是有这个特有领域(OA)有关的,你说得特别正确,所以当我在开发别的系统,比如教务管理系统,排课系统的时候,就必须针对其特有的性质进行一些必要的变动,当然这种变动是比较小的,因为大部分管理信息的需求实现是一样,只有核心算法是有区别的,但己经很小了,所以应用起来的时候,你可以提高一些效率,并且可以把注意力集中在你系统核心算法上去。
基于描述文本的解析部分也是比较简单的,起码说写的时候不会太多,可在设计的时候,不知道如何去作,所以就用了实现OA系统的需求来完善开发引擎的,实事两者属于共生性质的。两者依存,为什么呢,开发引擎设计的初意就是要提高OA系统的开发效率,就一点是必须的。所以就你中有我,我中有你了。
(设计方法)上面是关于设计方面的一些思想,下面就直接是如何去设计这个引擎了,其实引擎是一个很空的东西,没有一定的设计经验在里面,根本无法设计出合理的系统,不论生不生成中间代码,其中间执行的顺序与过程就是写代码代码的过程,其质量的好坏,也是由于你直接写的代码质量决定的。因为这个引擎是你开发,它超越不了你写的基本代码。所以这一部分就应该是基本代码应用怎么样来组织,怎么的组织可以让你程序更具有一些合理性。当然或许对我的方法有一些异议,没有关系,我也一直想听听别人的意见,来好好对我的代码进行一些必要性的组织。其也属于系统设计的范畴。