中国DOS联盟论坛 - Powered by Discuz! Board

标题: 面向对象的批处理语言（Object Oriented Batch Language） [打印本页]

作者: willsort 时间: 2005-8-4 19:46 标题: 面向对象的批处理语言（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 的命令行范例：

E:\Batch\Test\OOBL>project work

"work":class man

"work":proprt Name

"work":proprt FullName private

"work":method setName

set name=%1

set fullname=%2 %3

^Z

"work":method putName

echo Name:%name%; FullName:%fullname%

^Z

"work":class employee man

"work":proprt salary private

"work":method setSal

set salary=%1

^Z

"work":method putSal

echo Name:%name%; FullName:%fullname%; Salary:%salary%;

^Z

"work":man John

"work":John name=John

"work":man fred

"work":fred name=Fred

"work":fred setName Fred Fred Ford

"work":john putName

Name:John; FullName:

"work":fred putName

Name:Fred; FullName:Fred Ford

"work":employee bill

"work":bill name=Bill

"work":bill setSal $100000

"work":bill putSal

Name:Bill; FullName:; Salary:$100000;

"work":project :end

Project is end!

E:\Batch\Test\OOB>

OOBL 的批处理范例见附件

[ Last edited by willsort on 2005-8-4 at 19:47 ]

附件 1: OOBL.rar (2005-8-4 19:46, 5.89 K, 下载附件所需积分 1点 ,下载次数： 449)

作者: pandawy 时间: 2005-8-8 15:19
呵呵不错！

作者: GOTOmsdos 时间: 2005-8-11 13:16
启发思路不错.
不过,面向对象主要解决大型软件开发,或者能写出虽然小但能方便的调用WIN API的程序.
但,这跟BATCH的情况可能有点不吻合了..
BATCH加上外部命令总共才100左右的命令.
就好象,引进一艘航空母舰,只能放在内陆河一样..其作用就可想而知了..另一方面,反而造成运行减慢,,

另外,为了避免代码重写,BATCH已有了CALL.还可带参数,这有点象函数了...

不过,作为纯研究当然另当别论了..

作者: fdsiuha 时间: 2005-8-11 13:56
我觉得WIN的SCRIPT就很不错，批处理不是弱在程序流程控制，而是弱在数据类型和系统功能调用上面，只能使用内外部命令，没有系统级的API调用，有的时候必须为BATCH编写一个程序，才能完成并不是很复杂的工作。
至于OOP是不是应该在BATCH基本功能完善后再考虑？
你在文中也说到了必须使用外部命令，也是这个原因吧。
另外使用硬盘目录的拓扑结构模拟类的上下关系，我个人觉得不太恰当，至少能不能考虑使用内存虚拟的硬盘？另外目录结构也是有限制的。

其实让DOS支持REXX倒是比较好。

我对这个了解的不是太多，有说的不对的地方请原谅^^

[ Last edited by fdsiuha on 2005-8-20 at 21:54 ]

作者: willsort 时间: 2005-8-14 20:06
Re GOTOmsdos & fdsiuha:

   正如我在顶楼所说，此程序只是一个开发过程中的半成品，自然会有许多缺陷和弊病。但它引入了批处理编程的新思想，对我们开拓思路自然是很有益的。而我们的任务就是一步步地改善它，使它逐步达到实用的需要。

Re GOTOmsdos:

   OOP 是为方便调用 Win API，我是第一次听说，不知其依据何在。

   至于批处理命令少的问题，我是这样理解的，所有的语言都是基本语法关键字配合支持库而运作的，C语言也不过十几个关键字而已，其它全靠库里的函数和宏。而批处理的关键字（专用命令关键字）也是十几个，而它的支持库是DOS下所有的可执行程序，当然很多程序没有很好的接口。

   而 OOP 的实现也不仅仅是为了避免代码重写的，它还有很多其它的特征，比如我上文提到的数据封装。

Re fdsiuha:

   Win的script是不错，但它不是批处理，尽管它被称作“windows下的批处理”，它是另一种脚本，rexx也是一样，它们是具有很多优点，也可以轻松完成很多批处理难以完成的任务。

   但是我们可以发展和增强批处理，在所有可能的方向。批处理的基本功能是需要完善，比如变量类型（但大多数时候，我对这种类似Basic的泛型设计感到满意），比如错误处理（这我已作了一些工作），比如文本处理（我用debug和edlin完成了一些简单的实现），比如系统调用，比如外部支持库的引用（这个已经接近成熟）。

   至于内存虚拟盘，那还不是我们现在可以考虑的范畴，因为它还做不到大到足以影响系统性能的程度，到这个问题突出到我们不能容忍时，我们再讨论它也不晚。

作者: GOTOmsdos 时间: 2005-8-19 13:08

Quote:

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 ]

作者: Sandy 时间: 2005-8-19 13:36
这个...
最好还是用个perl之类的真正的scriptin' language
好一点

作者: willsort 时间: 2005-8-19 21:15
Re GOTOmsdos:

   看来兄还没有理解我上文中的本意。

   OOP中，数据封装和可重用性是同等重要的特征，没有谁前谁后之别，相比来说，OOP的数据封装的创新性更强一些，因为面向过程（POP）中的函数的可重用性也不是很差。

   至于函数的多寡，我已经说过了，函数只是高级语言的特化术语，广义上它是指运行支持库，这同C++的标准库，VS的MFC，Delphi的VCL，Java的J2SDK是相似的。批处理的运行库，就是基于它所运行的平台的所有的内外部命令，第三方程序、工具和软件（不论是否是命令行程序）等在批处理可直接或间接调用的所有代码和程序，当然它们的界面或接口不一定是标准的和友好的，这才显示出封装的必要性。

作者: defrag 时间: 2005-8-20 18:24
调用api可用rundll32命令

作者: fdsiuha 时间: 2005-8-20 22:18
这几天我一直在想，如果批处理文件做的过于复杂是舍本逐末的做法。单纯的“为技术而技术”并无实用价值。也可能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 ]

作者: willsort 时间: 2005-8-21 17:19
Re fdsiuha:

   两年前，我与你的想法是一致的——“不应该把批处理复杂化”。因为简单易用便是批处理最大的优势，如同它所在的宿主平台DOS一样。所以，我没有给与主楼提到的文献太多的关注。

   但是，现在我的想法发生了一些变化——“没有必要时，批处理不应该过分复杂”。因为，两年间，我的视野得到了扩展，我发现了很多具有相当复杂性的批处理程序，我自己也写了一些具有相当复杂性的批处理程序，所谓“存在的即是合理的”，无论其应不应该，它都已经出现了。

   如今，DOS到现在仍然能有存活的空间，已很难说是因为它的“简单”了——已经有很多用户抱怨，“DOS怎么那么难学？！”。从另一方面来看，它本身也许是简单的，从它的体积远小于Windows和Linux等同类系统；然而难易的尺度是相对移动的，构造上的简单不代表其使用上的简单，Windows为了实现鼠标轻轻的一个点击，付出的代价便是体积和性能消耗的急剧庞大。

   "Complex makes simple"这句话有其相当的合理性。所以，为了批处理的简单，做些复杂的工作是有必要的。正如Java为了实现对象回收的简单化，而采用代价相当大的对象自动回收机制一样。将使用者的复杂性转嫁给生产者，是一种必然的趋势。

   你的关于DOS内部支持OOP的想法不是也有类似的动机吗？

作者: electronixtar 时间: 2006-10-13 23:50
这么好的帖子不应该沉了。其实微软的意思就是用一个WSH来代替bat，但是vbs不够命令化，于是又参照UNIX出了个PowerShell。新的技术太多了，重要的是思想

willsort的境界已经达到了出神入化了，再顶帖怀念一下

[ Last edited by electronixtar on 2006-10-13 at 23:51 ]

作者: redtek 时间: 2006-10-14 00:46
这又是一次创新和进步：）
超级顶！！！

作者: redtek 时间: 2006-10-14 01:07
顶～～
这个　“@echo %dbg% off”　真有意思，想要调试的时候连批处理文件都不用改了：）

:: Sample.bat - Sample of OOBL

:: Will Sort - 2005-7-31

@echo %dbg% off

call project Work

.....

这方法好～：）
Set dbg=on　，
这就一句键入以后运行任何一个带有 @echo %dbg% off　的指令的批处理先会执行前面的 %dbg%　参数，哈哈……
顶～

C:\TEMP\Oop>set dbg=on

C:\TEMP\Oop>project.bat MyProj

on off

C:\TEMP\Oop>if "MyProj" == ":end" goto proje

C:\TEMP\Oop>prompt "MyProj":

"MyProj":md MyProj

而且，这个prompt的提示符真有点儿给人感觉进入了Dbase的圆点提示符时代，
象是真的在开发器里正在交互式键入命令的感觉一样！

[ Last edited by redtek on 2006-10-14 at 01:11 ]

作者: pengfei 时间: 2006-10-14 01:09
顶~~~ 没想到批处理也可以面向对象...

作者: redtek 时间: 2006-10-14 01:25
如果是　面向过程思想　使用批处理，
可以把自定义函数（子批处理文件，可以接收参数）放到 Include　命名（类似）的目录内，

例如：还可以把象pengfei和版主做的浮点运算等一系列已经接近完美的批处理做成函数库格式，每个函数一个文件，存入函数专有目录内。
这样积少成多，将来开发的时候，只需简单调用就行：）

 C:\TEMP\basic 的目录

2006-09-30  14:51    <DIR>          .

2006-09-30  14:51    <DIR>          ..

2006-09-30  14:51    <DIR>          Include

2006-09-30  14:51    <DIR>          Lib

使用ｏｏｐ思想超级棒！！！
楼主的技术是具有创新思维的！！！

目前不知道如果楼主的这个创造性实现了部分功能以后，
应用它的人我想可能是：

较精通ＤＯＳ命令、精通批处理编写、精通面向对象的程序开发并真正开发过一段时间（如ＪＡＶＡ等），
然后有着对技术狂热的执著……

作者: redtek 时间: 2006-10-14 01:28
没有执著和创造性思维就不能点亮世界～：）
再顶！！！
等待楼主源源不断的好想法～：）

作者: yiping1973 时间: 2006-10-16 00:24
面向对象的批处理？真的有必要么？对批处理真要有正确的认识了，复杂了不如直接做dos软件开发好了。
支持willsort的观点！

作者: skno 时间: 2007-4-30 06:31
如果想要面向对像又想要简单,可以试试 PYTHON.

作者: lzmyst 时间: 2007-5-4 14:53
思想不错。有一定的实际应用性。

作者: 77209341 时间: 2007-5-26 15:38 标题: vssss

[quote]Originally posted by redtek at 2006-10-14 01:07 AM:
顶～～
这个　“@echo %dbg% off”　真有意思，想要调试的时候连批处理文件都不用改了：）
]

作者: zhanbushi 时间: 2007-5-26 18:53
谢谢分享~~~~~~~~~~~~~~~

作者: IamWizard 时间: 2007-6-2 23:13
顶一下~~~~

作者: gmy 时间: 2007-6-3 12:44
我的理解：将BAT图形化，语言标准化（类VB）。

其实他的唯一意义在于程序的保护，执行效率会比原始BAT要慢。

作者: rocmagic 时间: 2007-10-16 18:27
厉害啊

作者: rocmagic 时间: 2007-10-16 18:28
先下了,谢谢了

作者: picat 时间: 2007-10-17 13:54
留个脚印，日后研究，谢谢楼主了。

作者: 58795362 时间: 2007-12-7 19:51
这样的贴子我是一定顶的，思路不错！

作者: plp626 时间: 2008-1-16 18:44
楼主的想法就是非凡,总走在我们前头,
不过,本人觉得这项工程任务量巨大!!!!
建议先把一些常用的任务的代码大家商讨下做个规范标准,然后,
建立头文件,做成函数库,再实践下.

Quote:

大家踊跃发表意见呀!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

作者: enjoyer 时间: 2008-1-16 23:30 标题: 好想法,有创见!!!

如果批处理的OOP实现了,那么任何应用程序岂不是都文本化了!!!以后大家共享软件的时候只要传文本就OK了,哈哈. 不过这时候版权问题不好弄啊:P
   如果效率够好的话(硬件速度越来越快,好象没有太大问题),那么开发程序也简单了(省去了许多工具Compiler/Assemblyer/Llinker),DOS本身就是一个大的开发环境啊,太有创意了!!!
   应该好好规划一下,这个说不定就是以后的发展方向呢(如果做的好,这一个特点可以超越Windows和其他图形界面的OS),支持楼主!!
   可以想象,那时侯DOS就纯粹只是一个kernal(洋葱的芯),在他的基础上可以运行n个应用程序甚至n个OS(洋葱的n层皮):D

   咱们的DOS也该考虑64位的架构了,要不然怎么发挥出它短小精悍的威力呢??在64位上面大规模使用批处理应该很有意义.

[ Last edited by enjoyer on 2008-1-17 at 12:21 AM ]

作者: ztwaker 时间: 2008-1-23 18:15
可以先考虑可行性——比如在理论上用一套公式证明其确实可行；

再考虑怎么做——OO化BAT——也不迟~……

作者: cxx 时间: 2009-2-23 20:54 标题: 顶

好东西，要顶一下

作者: youyun 时间: 2009-6-5 23:02
卡巴不让我下

作者: pinyin2003 时间: 2009-6-5 23:22
看看先，小菜先受教下

作者: kendos 时间: 2009-6-6 01:17 标题: 新鲜！

好

作者: xbyiauao 时间: 2009-6-6 02:33
您真内行，高手就是高手啊，顶了~~

作者: swrobin 时间: 2009-6-18 23:42
顶~~~ 没想到批处理也可以面向对象...

作者: czl1378 时间: 2009-6-19 23:11
元老会员...
铂金会员...
金牌会员...
高手的地盘..
初级用户。。。。

作者: doomstenjee 时间: 2009-6-23 22:31 标题: 牛BR