谁能用汇编的思想去理解delphi？谁能这么透彻？？？(20分)

计划跟不上变化呀，一个应用最重要的、也是最难的在于搞清楚用户究竟想要什么，
但是用户要么不知道，要么拿不定主意，要么朝三暮四，做过项目的兄弟都深有体会。
这牵涉到的不仅是对象设计的问题，还有数据库设计、具体技术的选择等很多东西，
高级语言把这些东西隔离开了，把程序员的注意力转嫁到语言本身的特性上去了。
再说对象设计的问题，实际工作当中我们经常碰到这样的情况：本来对象A和对象B分工
协作完成了用户的要求，并且也是我们认为最合理的，但是用户的新要求不断地迫使我们
把A和B中的独立的、完整的方法零零散散地摘出来，或者是再揉合成一个对象C，此时ABC
之间的关系已经远非我们所乐见的了。
说这个例子不是想讨论A和B到底应该怎么设计，而是请大家注意这样一个趋势——用户的
思维、也就是现实的思维是在朝着打破对象分界的方向发展的，拆来拆去，最后我们会发现
对象没有了（当然这是一个极端的说法，是为突出这一趋势）。我觉得这只能说明这种方法
本身就有问题，而不应该把希望寄托在“出了问题我总有办法改”上面，改的过程不就是对
自身的一种否定吗？
——一家之言，可能是我太理想化，希望哪位能指出问题的本质所在或是点明彻底的解决途径。

TO all:
科学的发展就是宏观的无限大和微观的无限小。
化整为零是构建大系统的唯一方法。软件的思想也一样，所以有了数据加算法，
有了对象，有了组件，目的不外乎是“操冲称象”。
方法无所谓好坏，解决问题是关键。但我们这些吃"软"饭之辈，一定要把握软件的
整体架构，知道发展方向，学习“善假于物”的方法。
当然，团结合作是我等炎黄子孙的软肋，否则，睡狮怎能沉睡！

建议你去学机器代码,都是0,1很简单

等待把RTOS和配套DELPHI编译器烧到心片中的人[]

不是有病吗???????????????????

有病!@

每种语言都有它的功力，正如刀剑一般~~~
还是小刀之类云云

不知大家还记得，八十年代未九十年代初，中国大地上正是一片加解密研究的大潮，
其中涉及的磁盘操作和bios中断等技术居于世界前列，当大家还为能用汇编写出一
套汉字系统而钦佩不已的时候，微软在干什么？微软创造了连普通人都可以接触电脑
的windows，创造了连一个初级程序员都可以很上手的VB！
在现在windows和VB大行其道的时候，我们的加解密技术和汉字系统哪去了？

没有东西是完美的.....
也没有人说面向对象能解决一切问题......
但不可否认,面向对象较面向过程要先进......

都他妈是牛人，但是有几个写过2000行的汇编。

做软件，效率好像是非常重要哦！

软件是做出来用的，又不是干别的什么，在我看来
作为研究，为了更好的了解基本的东西，为了将来写出更精练的程序，底部的东西是必须学的。
但作为项目的开发，高级语言足够了，毕竟我们要的是高效率的可用软件而不是什么高深的新技术。

黑匣是要打开的,但那只是用来理解和学习,具体实现时,只要利用黑匣就可以了.
学从难处学,用从易处用 ---- 其实Delphi就是这样的一种工具.

这实际上是因为所谓"软件危机"问题引起的,
随着程序的复杂程度增加,软件开发和维护的难度越来越大,
那些具体问题的难度反而相对比较次要了.
人们想了很多办法来克服复杂性问题,如: 向结构化(函数库),面向对象(类库)等,
其实这些"其实高级语言里的花里胡哨的“概念”"正是解决问题复杂程度的精髓.

如果说到可重用性，这正是面向对象的强项啊！
最典型的，delphi下的控件。帮大家省了多少事？

每个工具都有自己的目的，何必非要用螺丝刀炒鸡蛋哪？
除非是挑战自我、锻炼创造性思维能力。

编程的目的本身是为了促进和解放生产力[]！

呵呵，讨论很激烈嘛。
我对高级语言看法如下：
高级语言从名词上就知道其高级（别扔我臭袜子，还没说完），所以我们就不应该用基本
知识来看待它。仔细看看其高级内涵，只不过是基本元素组建。使用高级语言好处就是我们
能够忽略一些底层的东西，而将注意力更多的聚焦到用户需求方面。但是有利就有弊。它在
封装的同时，也将一定知识封装了，所以我们要学会使用它时，不得不去理解其思维方式，
以及每个接口，函数定义。这也就加重了我们开发负担。
加上国内急功近利的出版社，国产的书籍让我们更是头疼。一个也许简单的问题，看了几本
书就不知道什么东东了？想要查找类似函数说明，却不知道何处找？
上次想看JAVA，发现蔡学墉（在csdn的专家栏），他介绍的书很有层次感。感觉国外的书籍
很棒，也许源于技术就是国外的把。。

to 5rain6sky:
强烈反对你的逻辑！
我相信你有足够的项目分析经验，否则我以下的话等于白说！
你所谓的算法加数据结构是什么？难道不就是对象吗？我不知道你是如何理解面向对象的，
我认为如果全面理解的话，不会这样将用户需求变化与面向对象对立起来。我看过几本软件
工程方面的书籍，特别注意到有关用户需求变化的章节，否举了很多引人入胜的例子。只有
灵活地运用面向对象技术、用到面向对象技术，才能自如地应付用户需要不断的变化。中国
和国外不一样，很难将软件工程的概念完整地运用到项目实践中，因为中国用户的层次差。
不过这种情况正在一步步改善，而且现在已经比前两年好多了。
一个合格的系统分析员应该在设计对象的时候已经将用户可能的变化考虑进去了，或者在设
计中留有充分的余地。我们以简单的工资表为例来说明。大部分用户并不懂什么对象、什么
数据，这是你的事，用户只告诉你我有七八个工资项目，人员按部门来管理，等等。短短十
多个字，已经向你提出了整个项目的概况。你的第一次设计，两个对象：员工和部门。工资
项目只是员工的属性而已。这么设计你是失败的。用户用的时候发现，在编写期间又增加了
一个工资项。你推倒重来，进行第二次设计：增加一个对象：工资项。紧跟着不地避免，又
增加一个组合对象：人员-工资项组合对象。这样你的系统共涉及四个对象。完了吗？没完！
第三个月的时候用户拿出一份漂亮的工资汇总表，发现可以将不同部门的同一类人进行汇总！
你不得不进行第三次设计。增加一个对象：人员类别，并又给人员增加一个属性：类别。可
能你认为噩梦总算醒了，结果你又错了。聪明的用户在你的系统正式启用前发现了你的新的
设计漏洞，你不得不停下来修补...
谁是噩梦的终结者？还是面向对象。在你需要升级你的系统的时候，你不需要修改从前的东
西！因为你可以只需要重新设计你修改的部分，然后继承或重载从前的部分。你用的时候仿
佛一切都是重新设计的。你得到了什么？效率。
回到前面的例子。你的第一次设计失败完全是你的过错，你应该能够分析到什么可能需要扩
展然后留出接口。而第二次设计失败则完全是用户的过错。第一次设计过错你只能自己弥补，
而第二次设计过错你完全可以拒绝----如果你不拒绝说明你是个敬业者，但你所担的风险并
不大----当你的工资系统需要增加一个人员类别的时候，你只需要从原来的员工对象上继承
一个新的员工对象，增加一个属性，然后再增加一个新的类别对象而已。微斯人，吾谁与归？
老粗我就是从汇编出身的，我不仅写过超过2000行的汇编，还写过超过10000行的汇编。但我
知道，用汇编写一个经得起考验的应用系统，不仅效率上不允许，而且难写、难调、难维护，
代码也根本不可靠----对底层系统的依赖也是问题呀！当系统规模达到一定的时候，用汇编
就成了梦幻了。任何时候高级语言的成就是不容抹煞的，这并不仅仅是什么黑匣子、白匣子
的问题或者是什么封装之类的问题，而是一种唯一！2000年前人们盖一幢房子，得自己和泥、
打砖，现在人们盖房子已经不满足于用砖块、加气块了，现在已经用构件盖房子了！整片整
片的墙直接从工厂运出来将浇好的柱子连起来！朴素的施工员说，大工砌的墙有不平的，最
后需要拆了重砌，而构件墙既轻、施工方便快捷，又成本低，最最关键的：永远不需要返工！
因为每片墙出厂前已经通过的严格的检测！
听出来了吗？那片墙的英文名叫做Component。不知道是软件界跟建筑界学了，还是建筑界跟
软件界学的。反正道理都是一样。为什么说是唯一？这是由规模决定的。从前的系统640K内存，
现在640M内存。所以绝大部门情况下，只能用高级语言了！极偶尔的情况需要汇编：写写驱动
程序或者规模很小的东东，就如同在农村仍然有人自己打土坯盖房子一样。

说的好,帮助提前.