![]() |
中国DOS联盟-- 联合DOS 推动DOS 发展DOS --联盟域名:www.cn-dos.net 论坛域名:www.cn-dos.net/forum |
| 游客 | 登录 | 注册 | 会员 | 搜索 | 中国DOS联盟 |
|
中国DOS联盟论坛 现在时间是 2026-08-11 06:48 |
共 47,811 主题排行 / 349,897 发帖 / 今日 0 篇 / 48,256 会员排行 |
| DOS批处理 & 脚本技术(批处理室) » 面向对象的批处理语言(Object Oriented Batch Language) |
| 可打印版本 38,107 / 56 |
| 第1楼 willsort | 发表于 2005-08-04 19:46 |
| 元老会员 发帖 1,512 积分 4,432 | |
|
面向对象的批处理语言(Object Oriented Batch Language) 面向对象的批处理语言(Object Oriented Batch Language) 本文文本、代码和思想源自以下文献: 《BATCH PROGRAMMING ELEMENTS》(Dirk van Deun) Chap 9:“Object Oriented Batch Language” http://student.vub.ac.be/~dvandeun/batcoll.all !特别鸣谢 Dirk van Deun 做出的贡献! 两年前便见到了这篇文献,只是一直没有给与足够的关注,前几天突然翻出来,才 发觉其中潜藏的价值。其中“面向对象”的实现对批处理的编程思想做出了重要突破, 其以文件结构模拟数据结构的思想也对我有很大的启迪。 程序利用文件目录来模拟类库和对象库,以文件来模拟类所拥有的属性和方法,以 批处理来模拟对象的引用,从而实现了OOP 的四大结构:类、对象、属性和方法,也因 此实现了OOP 的继承和覆盖特性。 将程序彻底研究之后,我决定做出一些修改: 首先,将所有代码改用内部命令编写,最大限度地解决代码跨平台的可移植性。目 前进行和通过了 MSDOS6.22/7.10 和 WindowsXP命令行下的局部测试,我的设计目标是 能在 MSDOS/ Win9x / WinNT's 全系列平台下正常运行。 其次,将对象的定义方式和调用方式做出更改;即直接用类名定义对象,用对象名 引用属性和方法,使之更符合OOP 的代码书写习惯。 再次,改进了批处理中使用 OOBL 的方案;原程序虽然名为 OOBL ,但实际上它只 能工作于命令行,而无法将全部代码写入批处理中。 第四,增加了属性和方法的访问属性 public/private ,数据封装成为可能。 最后,将调用对象方法前的变量载入和调用后的变量保存策略做出较大修改。这个 修改是不得不然的,否则使用 Dirk 原本的 push/pop 方案,将会引入 edlin.exe这个 外部程序;但是这个新策略也带来了很多问题,对象的数据与类的数据明显重复,造成 了数据冗余和空间占用的问题日益突出。 目前为止,这是一个半成品,它仍然存在着相当大的缺陷。比如,为了结构的清晰 而未加入错误处理机制,至于设计中的对象的构造函数和方法的多态调用也还没有成熟 的方案。 但是,我现在的状态很糟糕,花了整整两个星期,进展却十分缓慢。所以,只得将 未成熟的代码放出,对此有兴趣的业内人士,可以研究看看,希望有人可以继续我未竟 的工作。 下面是 OOBL 的命令行范例: OOBL 的批处理范例见附件 [ Last edited by willsort on 2005-8-4 at 19:47 ] 附件 OOBL.rar (5.89 KiB) |
|
| 第2楼 pandawy | 发表于 2005-08-08 15:19 |
| 新手上路 发帖 5 积分 7 | |
|
呵呵不错!
|
|
| 第3楼 GOTOmsdos | 发表于 2005-08-11 13:16 |
| 铂金会员 发帖 1,827 积分 5,154 | |
|
启发思路不错.
不过,面向对象主要解决大型软件开发,或者能写出虽然小但能方便的调用WIN API的程序. 但,这跟BATCH的情况可能有点不吻合了.. BATCH加上外部命令总共才100左右的命令. 就好象,引进一艘航空母舰,只能放在内陆河一样..其作用就可想而知了..另一方面,反而造成运行减慢,, 另外,为了避免代码重写,BATCH已有了CALL.还可带参数,这有点象函数了... 不过,作为纯研究当然另当别论了.. |
|
| 第4楼 fdsiuha | 发表于 2005-08-11 13:56 |
| 高级用户 发帖 302 积分 587 | |
|
我觉得WIN的SCRIPT就很不错,批处理不是弱在程序流程控制,而是弱在数据类型和系统功能调用上面,只能使用内外部命令,没有系统级的API调用,有的时候必须为BATCH编写一个程序,才能完成并不是很复杂的工作。
至于OOP是不是应该在BATCH基本功能完善后再考虑? 你在文中也说到了必须使用外部命令,也是这个原因吧。 另外使用硬盘目录的拓扑结构模拟类的上下关系,我个人觉得不太恰当,至少能不能考虑使用内存虚拟的硬盘?另外目录结构也是有限制的。 其实让DOS支持REXX倒是比较好。 我对这个了解的不是太多,有说的不对的地方请原谅^^ [ Last edited by fdsiuha on 2005-8-20 at 21:54 ] |
|
| 第5楼 willsort | 发表于 2005-08-14 20:06 |
| 元老会员 发帖 1,512 积分 4,432 | |
|
Re GOTOmsdos & fdsiuha:
正如我在顶楼所说,此程序只是一个开发过程中的半成品,自然会有许多缺陷和弊病。但它引入了批处理编程的新思想,对我们开拓思路自然是很有益的。而我们的任务就是一步步地改善它,使它逐步达到实用的需要。 Re GOTOmsdos: OOP 是为方便调用 Win API,我是第一次听说,不知其依据何在。 至于批处理命令少的问题,我是这样理解的,所有的语言都是基本语法关键字配合支持库而运作的,C语言也不过十几个关键字而已,其它全靠库里的函数和宏。而批处理的关键字(专用命令关键字)也是十几个,而它的支持库是DOS下所有的可执行程序,当然很多程序没有很好的接口。 而 OOP 的实现也不仅仅是为了避免代码重写的,它还有很多其它的特征,比如我上文提到的数据封装。 Re fdsiuha: Win的script是不错,但它不是批处理,尽管它被称作“windows下的批处理”,它是另一种脚本,rexx也是一样,它们是具有很多优点,也可以轻松完成很多批处理难以完成的任务。 但是我们可以发展和增强批处理,在所有可能的方向。批处理的基本功能是需要完善,比如变量类型(但大多数时候,我对这种类似Basic的泛型设计感到满意),比如错误处理(这我已作了一些工作),比如文本处理(我用debug和edlin完成了一些简单的实现),比如系统调用,比如外部支持库的引用(这个已经接近成熟)。 至于内存虚拟盘,那还不是我们现在可以考虑的范畴,因为它还做不到大到足以影响系统性能的程度,到这个问题突出到我们不能容忍时,我们再讨论它也不晚。 |
|
| 第6楼 GOTOmsdos | 发表于 2005-08-19 13:08 |
| 铂金会员 发帖 1,827 积分 5,154 | |
OOP 是为方便调用 Win API,我是第一次听说,不知其依据何在。 哦, 我这话主要是针对写WIN程序的情况下,当然不是指全部的OOP.. 另, OOP的思想不主要在封装,而是先作成可重用的类,以便调用.所以有类库嘛,对WIN,就有弄好的MFC,这样,写程序时就要调用他们. 反过来说,没有类调用,OOP就没意义了.. 但要有大量的函数才有必要封装啊.. DOS BATCH 没有啊, 即使可做出一些类似函数的小块, 但数量难以成规模啊.. 不知道,其他的脚本语言有没有涉及到类?,比如 UNIX 等的 SHELL 等, 他要比DOS BATCH 丰富的多哦... [ Last edited by GOTOmsdos on 2005-8-19 at 13:15 ] |
|
| 第7楼 Sandy | 发表于 2005-08-19 13:36 |
| 元老会员 发帖 157 积分 608 | |
|
这个...
最好还是用个perl之类的真正的scriptin' language 好一点 |
|
| 第8楼 willsort | 发表于 2005-08-19 21:15 |
| 元老会员 发帖 1,512 积分 4,432 | |
|
Re GOTOmsdos:
看来兄还没有理解我上文中的本意。 OOP中,数据封装和可重用性是同等重要的特征,没有谁前谁后之别,相比来说,OOP的数据封装的创新性更强一些,因为面向过程(POP)中的函数的可重用性也不是很差。 至于函数的多寡,我已经说过了,函数只是高级语言的特化术语,广义上它是指运行支持库,这同C++的标准库,VS的MFC,Delphi的VCL,Java的J2SDK是相似的。批处理的运行库,就是基于它所运行的平台的所有的内外部命令,第三方程序、工具和软件(不论是否是命令行程序)等在批处理可直接或间接调用的所有代码和程序,当然它们的界面或接口不一定是标准的和友好的,这才显示出封装的必要性。 |
|
| 第9楼 defrag | 发表于 2005-08-20 18:24 |
| 中级用户 发帖 570 积分 456 | |
|
调用api可用rundll32命令
|
|
| 第10楼 fdsiuha | 发表于 2005-08-20 22:18 |
| 高级用户 发帖 302 积分 587 | |
|
这几天我一直在想,如果批处理文件做的过于复杂是舍本逐末的做法。单纯的“为技术而技术”并无实用价值。也可能GOTOmsdos就是这样想的。现有的批处理和内部命令命令上实现了完整的OOP功能并不会给一般用户带来好处,反而使该“二次开发”的批处理文件难以理解,更不要说实用化。
批处理文件的优点是每一行都是内部命令/批处理命令,或外部命令/应用程序。如此一来只要对DOS稍微熟悉、比较频繁使用某些命令的人,都能够应用批处理。不用学数据结构、不用理解OOP,也不用学习某一具体语言。 另一个优点是文本易于修改、灵活方便。一般的语言需要编译或解释器才能运行(COMMAND.com在这里相当于一个解释器)。要不我随便使用个OOP语言,都有调用SHELL命令行的功能,以代替批处理。而且OOP功能一应具全,也比DOS批处理也容易理解。 因此我不赞成OOP是批处理发展的一个方向,不应该把批处理复杂化。但我绝不是认为楼主的想法不好,作为学习讨论OOP的实现载体确实值得研究。但研究的对象不是研究批处理本身而是OOP。就像用自展技术编写该语言编译器本身,其实并没有多少实用价值,但至少能证明这件事是可行的。 PS:如果DOS内部支持批处理的结构化和OOP化,也是很好的而且有可能的,但是COMMAND.COM文件略微需要增加些“体重”,系统的开销也要稍微大些 [ Last edited by fdsiuha on 2005-8-20 at 22:48 ] |
|
| 第11楼 willsort | 发表于 2005-08-21 17:19 |
| 元老会员 发帖 1,512 积分 4,432 | |
|
Re fdsiuha:
两年前,我与你的想法是一致的——“不应该把批处理复杂化”。因为简单易用便是批处理最大的优势,如同它所在的宿主平台DOS一样。所以,我没有给与主楼提到的文献太多的关注。 但是,现在我的想法发生了一些变化——“没有必要时,批处理不应该过分复杂”。因为,两年间,我的视野得到了扩展,我发现了很多具有相当复杂性的批处理程序,我自己也写了一些具有相当复杂性的批处理程序,所谓“存在的即是合理的”,无论其应不应该,它都已经出现了。 如今,DOS到现在仍然能有存活的空间,已很难说是因为它的“简单”了——已经有很多用户抱怨,“DOS怎么那么难学?!”。从另一方面来看,它本身也许是简单的,从它的体积远小于Windows和Linux等同类系统;然而难易的尺度是相对移动的,构造上的简单不代表其使用上的简单,Windows为了实现鼠标轻轻的一个点击,付出的代价便是体积和性能消耗的急剧庞大。 "Complex makes simple"这句话有其相当的合理性。所以,为了批处理的简单,做些复杂的工作是有必要的。正如Java为了实现对象回收的简单化,而采用代价相当大的对象自动回收机制一样。将使用者的复杂性转嫁给生产者,是一种必然的趋势。 你的关于DOS内部支持OOP的想法不是也有类似的动机吗? |
|
| 第12楼 electronixtar | 发表于 2006-10-13 23:50 |
| 铂金会员 发帖 2,672 积分 7,493 | |
|
这么好的帖子不应该沉了。其实微软的意思就是用一个WSH来代替bat,但是vbs不够命令化,于是又参照UNIX出了个PowerShell。新的技术太多了,重要的是思想
willsort的境界已经达到了出神入化了,再顶帖怀念一下 [ Last edited by electronixtar on 2006-10-13 at 23:51 ] |
|
| 第13楼 redtek | 发表于 2006-10-14 00:46 |
| 金牌会员 发帖 1,147 积分 2,902 | |
|
这又是一次创新和进步:)
超级顶!!! |
|
| 第14楼 redtek | 发表于 2006-10-14 01:07 |
| 金牌会员 发帖 1,147 积分 2,902 | |
|
顶~~
这个 “@echo %dbg% off” 真有意思,想要调试的时候连批处理文件都不用改了:) 这方法好~:) Set dbg=on , 这就一句键入以后运行任何一个带有 @echo %dbg% off 的指令的批处理先会执行前面的 %dbg% 参数,哈哈…… 顶~ 而且,这个prompt的提示符真有点儿给人感觉进入了Dbase的圆点提示符时代, 象是真的在开发器里正在交互式键入命令的感觉一样! [ Last edited by redtek on 2006-10-14 at 01:11 ] |
|
| 第15楼 pengfei | 发表于 2006-10-14 01:09 |
| 银牌会员 发帖 485 积分 1,218 来自 湖南.娄底 | |
|
顶~~~ 没想到批处理也可以面向对象...
|
|
| 1 2 3 4 下一页 |
|
[ 联系联盟系统管理团队 -
中国DOS联盟 -
标准版 ] Sponsored by ifanr Inc | © 2001–2023 |