请问各位：在面向过程的设计中，使用什么方式描述处理过程是最优的？

[zf0579]

在面向对象的设计中，常用的描述方式是采用UML。那么在面向过程的设计中，最好采用什么方式呢？采用流程图这种方框+线条的方式实在不是个很好的描述方式。
这个问题有些土，但是在很多领域，特别是底层软件设计时，面向过程还是大大有用的。

[zf0579]

可我不想面向对象，我想面向过程，虽然落伍。我知道大家都在C++,C#，Jave，可我由于在底层开发只能用C，最好是ASM，从语言上根本上不支持OOD。在做设计时，方框+线条的流图有其局限，所以想知道更好的表示方式。

[w_rose]

真是没办法了，那你不需要了解任何“更好的表示方式”了。

只懂得汇编语言的人也需要使用面向对象方法来设计呀？！面向对象方法可以和汇编语言的特殊书写方法一一对应呀。何况c。实在太奇怪了？

[w_rose]

你把面向对象贬低成C++,Java了，或者把面向对象的设计方法贬低成OOD了（可恶的OOD，害人！）。

[zf0579]

呵呵 可能是我知道太少 那么什么是面向对象的定义啊？ 复用、重载、派生等方式是不是面向对象设计所必须的啊？ 怎么跟ASM、C对应上啊？怎么跟ASM C联系上啊，求教啦 ：）
还有，我可没有想贬低C++，Java，但是工具是实现思想所必须的啊。否则很难理解在面向对象设计思想提出很久之后，都不能流行的原因。是C++第一个为面向对象设计提供了实现的工具。我说得没错吧。呵呵

[spiker_h]

就是度的问题，再进一步机器语言也是可以面向对象的，只不过对象是0，1罢了，这篇文章没什么意思，讲的就是模块化设计的概念。简单对象设计从来就有，这种面对对象不能说不是面对对象，但非要把这种设计和面对对象完全等同比较勉强。

[w_rose]

结构化编程风格是伟大的。他将程序分成一小段一小段函数（过程），然后其他地方只需要一条语句就可以重复使用这段程序。不仅减少了程序员工作量，而且软件编译成的目标代码也很小，适合于内存很小的机器使用。在30年前，如果程序员有一段代码在其他地方重复录入了，一定会被老板骂。今天情况不同了——原因是今天软件公司的老板不再有能力逐行审查程序员的成果了，从程序员角度看他们的老板在编程方面通常是饭桶（对不起，我也许可算老板，但我也是最辛勤的程序员）。

但是，即使30年前，结构化编程也不是成为软件高手的最主要手段。试想一下，当年盖茨在4K内存运行条件下书写了Basic语言，这个系统可以读入纸带，在内存中编辑程序，进行计算并且输出结果，还能将程序写到纸带上，俨然一个小型操作系统，它的主要手段就在于软件代码被重复使用的频率很高。今天有人能超过他吗？但是如此麻烦的代码，他又怎样保持设计时头脑清醒的呢？（他可是“意大利面条式的GoTo”语句的典型代表)

看一看任何一个早期操作系统的程序代码，不难发现他们到处是“空洞”——他们是各种应用程序的“代理”。比如一个字处理程序要在用户按键时立即显示帮助信息，它必须“愚弄”操作系统，即用自身的一段代码取代操作系统的对键盘按键的响应代码。通常在操作系统必须运行的地方插入一条跳转命令，然后自己的这短代码运行完之后再返回操作系统被插入的地方的下一条命令。操作系统浑然不知的情况下被篡改了！盖茨这种软件“黑客”最擅长此道，他们拿到一个1万行的程序，只需要在后边追加1百行就可以当成全新的新软件推出了（注意是追加，因为原有的代码一旦有变动其运行稳定性就往往会立即下降，如果只有别人开发的目标代码则根本不敢改变旧程序），而用户还以为是从头开发的呢！今天的软件大亨大部分人那个时候都是地地道道的“黑客”。

但是这种给软件“开天窗”的技术竟然在“结构化编程”中被故意抹煞了（害人）！标准Pascal语言根本没有这种方法。(Pascal的引入就是为了统治结构化编程方法的，它的衰落大概是因为当年的“黑客”讨厌他，而这些黑客日后都成大气了吧)

OO不过是公开了他们的未公开技术，但是用了安全的语法，需要程序员预先声明哪些代码需要将来被重新覆盖。

今天，能够使用继承但是不会尽可能使用“覆盖”方法的程序OO员还没入门呢，他们必然随着工作年头的增多不断重复编写类似的代码，因为他们脑袋中根本没有相应的需求！








设计是这样一种过程：我们分析和定义几十或者几百个事件的条件以及结果，然后运行一个图形编译器，它自动给我们产生一幅或者几幅所要的将事件前后联系起来的图形。我们可以随意给出一个测试系统的初始状态集合和目标状态集合，它可以告诉我们这个图能否从初始状态达到目标状态。通过对需要避免目标状态进行分析，我们可以逐步增加一些事件的约束条件，反复运行这个编译器，直到它产生的设计图恰好可以产生正确的目标，并且可以避免错误目标。

我们可以把这些事件定义像排列名片一样随意安排先后次序，但编译的结果是一样的，这就是“说明性”而非“过程性”的设计风格。

也许你说“我没见过这样的编译器呀”？对了！擅长设计的人是在头脑中进行这个编译的，但是总有一天会有人把它写成程序供大家共享。既然难得见到现成的产品，所以它暂时还是一门时兴的“学问”，需要亲自向专家学习，并且掌握。

好多人靠“拍脑袋瓜”碰运气来画图。

你熟练掌握这个“编译系统”原理以后，才具有运用它实际设计新系统的能力。而那些可以从书上抄来的已经画好的图只是这个过程的结果而不是原因。研究设计方法完全是为了自己掌握如何从原因得到结果的过程。好多人以为设计就是以画出图来为开始的，我却觉得90%以上的时间是在研究一个个离散的事件的定义格式，真正进行画图往往是最后很自然的结果。其实从事件定义到状态图的过程是完全机械的，很简单的（只要准确），计算机远远比人擅长。人应当做那部分真正有价值的工作。






我可以举出一段简单的VB代码来解释什么是面向对象风格：

假设我们对任意具有整数下标的数据集合进行排序，注意Pos1和Pos2是下标：

public class ArraySort

protected mustoverride sub Swap(byval Pos1 as int32, _
byval Pos2 as int32) '交换元素
protected mustoverride function Order(byval Pos1 as int32, _
byval Pos2 as int32) as boolean '判断两个元素是否顺序

public sub QuickSort(byval From as int32,byval To as int32)
if From>=To then exit sub

dim p as int32
p=Part(From,From+1,To)
call Swap(From,p)
Call QuickSort(From,p-1)
Call QuickSort(p+1,To)
end sub

private function Part(byval P as int32,byval From as int32, _
byval To as int32) as int32
do until From>=To
if Order(From,P) then
From+=1
else
Call Swap(From,To)
To-=1
end if
loop
return To
end sub
end class

上述代码可以对任意类型数据集合（只要可以按照整数索引进行访问）快速排序。比如，我们可对52张扑克牌进行排序。

我们可以编译这个对象，并且发行给其他程序员。他们可以直接引用，对任意业务对象集合进行排序。

思维停留在结构化层面上的程序员会疑惑：事先不知道所排序的数据类型呀？ 没有定义如何交换元素呀？ 不知道怎么比大小呀？这恰恰是我们使用面向对象风格的主要原因。

考虑一个开发组中，任何实现复杂组件的程序员都不必等待、研究、跟随其他程序员开发的组件的接口定义。你在开发自己的组件时根本不必引用别人的组件，你可以完全自主地进行设计、测试、书写文档，并且在这个对象可能处理的业务数据还一个都没有开发出来之前就完成你的开发工作，发行组件对象。别人不管怎么修改其它的对象定义，都不会影响到你的组件，你再也不用轻易地回过头来修改自己的代码。

在上述代码中，如果将处理的对象、或者虚拟的操作明确了，那么你可能需要将来用编辑器的剪贴板把这段程序拷过去，然后修改很少的一点点代码，以便适应新的对象或者不同的Order或者Swap操作。而这正是面向对象风格编程的大忌。

总之：面向对象的风格使我们可以“从需求开始”编写程序，也就是说在细节没有确定之前首先开发高层次的代码。

实际开发中，我们总是混合自顶向下和自底向上的编程方法，只要恰好与我们分析、设计系统所用的思维方法一致，就可以在将来修改系统时少犯错误。如果其中有10%的对象是自顶向下定义的，那么就足以证明非常精通对象了。

有趣的是，很多程序员认为只要有class定义关键字、并且子类可以继承父类的属性和操作就算是满足面向对象编程的充分条件了！？







肯定没有讨论分析和设计，对吧！要是讨论那个，我得讨论什么是稳定的关系、多余的关系如何简化为属性、多重继承如何简化为单继承、状态为什么也是一种对象、状态如何分类和继承、如何确定状态之间的关系，等等等等。繁琐但是并不难理解，好像不需要“呕心沥血”。






我前两天写的那篇小东西只是从程序员自己关心的角度来看面向对象的意义。对非程序员来说，很容易因为不了解编写程序的过程而误解我的意思。

继承确实可以让我们定义子类的数据结构时不必重复书写父类的数据结构，从而省却一点点代码，但是这远远没有充分说明面向对象的真实意义，还要考虑在编程过程中真正不需要重写程序本身。因为对程序的重写比对数据结构的重写带来的危害要大。

有人说我在这段代码中没有封装复杂的数据结构，所以不是面向对象的。说实在的，在写完它之后，我才意识到会有很多人因此而误会。如果需要我拼凑一堆数据，我可以把关于排序算法的历史做成属性拼凑到这个类中，难道这个类因此就面向对象了？

还有人说这个反映了算法，因此不是面向对象的。与大学里的数据结构或者算法的教材相比，我强调的是这个类是针对更高级的排序对象的。你可以随便找一本数据结构中快速排序的算法代码来，然后考虑一下，如果待排序的对象是一副扑克牌，那么那个算法是否需要重写？算法本来无所谓是否面向对象，有问题的是我们的教育方法。

面向对象的关键就是在我们写程序是可以用非常精炼的（但是不会带来运行时的过分开销）的方法来表达。计算机程序员所理解的程序和语言学家所理解的程序当然不同，计算机程序员所理解的程序可以变成软件商品，但是语言学家的程序只能传授给别人用来思维和说话。因此我说对于程序员最直接的经验对于非程序员不一定能立即理解，需要换一种更浅显的与项目开发无关的方法来表述。但是有一点是基本的，表达对象的方法也是对象。否则，你就只能重复或者漠视别人表达的“对象”，没有权利评论别人表达的是非了。别忘了，我那里只是针对程序员开发过程来谈的呀！在我看来，如果在那里我只谈封装数据结构，就把面向对象方法给贬值了。

好像不只一人问过我c中的qsort是不是“面向对象”了。我只能从程序员的角度回答这个问题，否则又会引来好多酷爱哲学批评的人。如果你随便写一个数据结构，然后把指针传递给qsort，你在开发阶段看不出任何错误，只不过在程序运行时系统内存乱了，系统崩溃了而已。但是你用继承语法，你永远不会干出这样的蠢事。正是因为考虑这种差别的原因，我才理解如何在开发中需要关注面向对象方法。

很多人不关心“方法也是对象”，实在没事可做的结果就是到处纠缠“是不是”对象的判断。面向对象方法的核心是对象之间的关系，为了这些关系的简明实用，我们需要对象有同样实用的属性。事实是，如果不考虑过程的简练性，如果

[w_rose]

这个“面向对象设计风格”的文章恰好回答你的问题。你是否对“面向对象”有了新的概念。

[w_rose]

面向对象是离不开面向过程的。