[自序]
本来打算这一段时间好好补补算法知识，多写点程序而少写些文字。但今天突然对程序结构有所感悟，不由得写下了这篇文章。
[正文]
所谓程序结构，就是指通常人们所说的“结构化编程”、“面向对象编程”等等。通常，最常见的程序结构包括：
当然，还有很多程序结构如“面向组件”程序和“面向方面”程序等等，这些是我所不了解的，不便细说。通常一提到非结构化程序，人们自然而然地会想起汇编语言程序；同时，C语言也可以编写一些非结构化的程序。而结构化程序就多得很了，几乎在高级语言刚出现的时候，所有的高级语言都是结构化的，如FORTRAN、Pascal、C等等。至于面向对象程序，我就更不用说了，现在漫山遍野都是面向对象编程的声音，这类编程语言也有很多，如C++（它并不是纯面向对象的）、Java、C#等。
我这里所想到的，并不是这些语言的应用，而是这些程序结构（以及支持它们的编程语言）之间的辩证关系。
非结构化程序为当今很多程序员所不齿，认为这是一种不好的编程风格。但是，以汇编语言为代表的非结构程序编程语言却是最能直接表达机器行为的，用这些语言编写的这些程序，通常可以以最高的效率运行在特定的平台上。当然，这也要冒着最大的风险并且付出最大的努力。但是，非结构化程序也可以体现出其结构化的一面。譬如，几乎所有的汇编语言都提供call/ret、PROC/ENDP等语言构造以支持结构化程序的编写。因此，在为了效率而不得不使用汇编语言编写程序的时候，我们应该在追求效率的同时尽量地使用这些语言特性，使得程序更具结构化，这对于代码维护来说是相当重要的。即便你工作在一个非常低级的平台上，该平台的汇编语言不支持call/ret，我们也应该以明确的代码通过利用跳转指令来达到结构化目的。
在结构化程序设计语言出现伊始，人们就为其深深吸引。确实，明确的代码意图、清晰的程序结构使得程序设计不再是一种煎熬，对于代码维护人员来说更是一个福音。因此，结构化程序设计思想以迅雷不及掩耳之势席卷人们的思维，而结构化程序设计语言更是如雨后春笋般地出现。但是，在大家盲目地追求结构化时，我认为，我们应该根据所解决问题的范畴进行灵活的思辨。如果我们为了追求更低的风险和更高的可维护性而使用结构化程序设计语言来书写底层应用，我们应该考虑在结构化程序中引入非结构化思想，譬如，使用全局变量避免函数调用中的传参，使用宏来代替函数调用以减少调用开销等等。当然，这些都是很危险的，要求有很高的语言控制能力才能够完成。另外，如果我们希望我们的代码具有更高的可重用性，我们还可以考虑把面向对象的思想引入到结构化程序设计中，如通过结构体等来保存数据，在一个单独的库中对某一特定类型的结构体定义特定的操作等等。当然，这也是危险的，我们不应该在结构化程序中过度地模拟面向对象程序结构，否则会适得其反，使代码变得一团糟，毫无可读性。
最后，面向对象席卷大地20余年了，其思想可谓深入人心。它是目前最先进的程序设计结构了（其他如“面向组件”、“面向方面”等等不过是对面向对象程序设计的补充和完善）。但是，在其中我们还是能够找到非面向对象的一面。通常，一个对象只有其公共成员和接口成员才是真正为“面向对象”所用的，在它的内部，却相当于一个小型库，其间不乏结构化程序甚至非结构化程序。譬如，我们通常用一些私有成员函数（方法）来辅助公共成员完成特定任务。那么，这些成员便构成了一个对象中的结构化程序，有时，为了效率的考虑，我们将一些数据实现为私有数据成员，好像这个小型库中的全局变量一样，这样在私有成员函数之间互相调用时，就可以减少一些传参的动作。这不就是非结构化思想了么。
上面一同胡侃，大概地说了说在某种程序结构中对另外一种或几种程序结构的体现。我们在实际的编程中，应该根据所要解决的问题灵活地选择一种程序结构，并灵活地运用语言特性适度地体现其他结构的思想，以达到效率和可读性、可维护性之间的最佳平衡。当然，这是一个权衡的过程，也是要求程序写作者有很强的程序写作能力的。还是要多多锻炼，尤其注意锻炼思维的灵活性。
发表于 @ 2004年08月21日 07:35:00|评论(loading...)|编辑