这个问题扎看起来很傻，我们的开发工具都是面向对象的，开发出的程序当然也都是面向对象的了。但是想想看，我们几乎是在被强迫的使用面向对象的思想。除非是设计组件，或者需要重写某些类，否则我们几乎从不自己定义类并创建它的对象。我们只是重复着：在数据模板上放上数据库组件，把它们连起来，窗体上放上几个按钮，在按钮的事件里敲入代码，运行丝毫没想到“OO”的事。以前看到过篇文章，讨论OO程序设计，它把所有问题都放在一个类里，类里定义方法再去具体实现功能。比如：T人事管理，里面有public procedure 人事调动；然后在对它进行代码设计。我觉得这样比仅仅对窗体上那个“人事调动”按钮的Onclick事件进行代码设计要好，这才是真的面向对象思想。但是随着时间的推移，我的这个想法又有点动摇了。因为我看到的各种书籍，网上的例程，甚至包括Delphi的demo，没有一个人是这么设计的。相信各位也很少有这么使用OO的。我的问题很简单，就是到底要不要将问题都OO？还是这种方法纯粹多余，应该放弃？我知道这不是什么原则问题，但是它关系到编程风格，这对我这个刚开始进入程序员世界的菜鸟很重要。谢谢大家，望请费心指教。
这个问题扎看起来很傻，我们的开发工具都是面向对象的，开发出的程序当然也都是面向对象的了。但是想想看，我们几乎是在被强迫的使用面向对象的思想。除非是设计组件，或者需要重写某些类，否则我们几乎从不自己定义类并创建它的对象。我们只是重复着：在数据模板上放上数据库组件，把它们连起来，窗体上放上几个按钮，在按钮的事件里敲入代码，运行丝毫没想到“OO”的事。以前看到过篇文章，讨论OO程序设计，它把所有问题都放在一个类里，类里定义方法再去具体实现功能。比如：T人事管理，里面有public procedure 人事调动；然后在对它进行代码设计。我觉得这样比仅仅对窗体上那个“人事调动”按钮的Onclick事件进行代码设计要好，这才是真的面向对象思想。但是随着时间的推移，我的这个想法又有点动摇了。因为我看到的各种书籍，网上的例程，甚至包括Delphi的demo，没有一个人是这么设计的。相信各位也很少有这么使用OO的。我的问题很简单，就是到底要不要将问题都OO？还是这种方法纯粹多余，应该放弃？我知道这不是什么原则问题，但是它关系到编程风格，这对我这个刚开始进入程序员世界的菜鸟很重要。谢谢大家，望请费心指教。
而OO思想中最重要的一点就是多态（多态依赖于继承和封装，而继承原来于封装），而多态良好的对变化进行了封装（多态将变化封装在动态环境中而继承则将变化进行实现，但限制与静态中），因此到目前为止，OO思想是最能反映模拟被观察世界的方式（因为他还源于人类认识世界的方式）。或许将来可能有更先进的理论，或许你在实际编程中可以不用OO，但知道了也没什么坏处，不是吗？
用delphi开发数据库，delphi提供的前台的基础功能基本上够用，至于选择哪一种方式效率高些，也要看在那些方面应用。Delphi很多不是很好做得东西，在后台数据库通过存储
过程等数据库提供得功能做，也可弥补，但这样对程序员的要求比较高，而且移植性比较差。其实在某种意义上讲我感觉我们现在的编程有点象罗伯特.清绮所说的老鼠赛跑。
追求效益的实用主义和追求技术的理想主义之间的矛盾。我认为人类的发展的过程就是对自己能力的一个扩充过程，一方面是弥补自己的不足，另一方面是对自己的模仿，或兼而有之。照相技术，汽车技术都是，计算机也不列外，不过计算机是对人的思维的一种模仿，（这种模仿超过了以往的任何一种模仿，人开始对自己核心本质进行模仿）因此我不赞同一些朋友说计算机就是0,1的说法。计算机是0，1其实只是计算机的一种物理实现。就好像计算机是一个类，而采用0，1的计算机只是一个实例，或子类的实例。无论是面向对象，还是面向过程都是一种思维模式，其目的是为了描述现实世界和解决现实世界的问题，当然面向对象是更高层次的，更抽象的思维方式。这两种方式也不存在谁代替谁，谁比谁好的问题。说的简单一点它们是一个事物的两个表现：宏观和微观（这个比喻是否恰当我也拿不准，还在思考，先写出来，大家可以讨论）。
至于计算机软件中先出现面向过程后出现面向对象，这纯粹是技术问题。当然这也符合人类的
认知过程，先具体后抽象；先微观后宏观。
to FrameSniper(§无形的质§) :很有深度。
标准很多，但哪种标准最适合却又是个问题
软件开发的过程无非就是现实世界的问题域到计算机空间的解域之间的映射过程，这种映射的过程也是运动——变化的。映射这种过程本身就像一条线段（不是直线哦！），既然是线段，那么肯定就有两个端点了，线段的起点是现实世界中我们碰到的各种有待解决的问题，而线段的终点就是我们利用计算机设计出的解决问题方案（软件是这种方案的具体体现）。我们看待现实世界中的各种问题的时候选择的角度不同则会诞生不同的开发理论，例如面向过程和面向对象都是如此；而在线段的终点——软件（解决问题方案，即解域）的构成直接体现了起点所使用的角度——例如以前没有OO理论的时候我们使用OP（面向过程）的语言来创建软件，那个时候我们的软件中没有任何OO的思想（也不能说完全没有，至少是没有完全清晰的OO思想），但随着对各种缺憾的担心和弥补（这也是任何科学的发展的动力，即追求完美），人们看待现实世界问题域中的问题的观点改变了——问题不再是仅仅由过程组成，过程成为了参与业务的各个参与方发出的活动的代名词，在这个时候，过程成了配角，激发过程（即发出的活动）的事物——参与方成了主角！这个观点符合人们看待问题的方式（人类在将自己的创造与自己的行为不断的进行吻合，最后彻底地用自己的创造代替自己的行为，甚至优化自己的行为），因此出现了OO理论。
OO理论不应该是计算机世界解域中的事物，其实也不是。OO理论在计算机世界中的体现就是现在流行的各种OOL和OOD方法。
是否符合人类认知世界的观点可以作为比较各种开发理论的标准，而且从目前的软件开发潮流来说是最合适的一种标准，或许将来不是。从细节来说，OO理论的内容非常多，任何学习软件开发的人都应该去学习实践这个理论（这绝对不是什么“水到渠成”的事情，这么说只能说明持这种观点的人根本不知道OO到底是什么）。
最简单的程序，可以直接结构化设计的，就没有必要强制OO；
就跟做菜是否需要酱油一样简单不过的事；若是OO的狂热分子，将OO做为信仰的，那是另一回事。
“多态将变化封装在动态环境中而继承则将变化进行实现，但限制与静态中”
“面对大规模问题的时候，结构化设计只可能无限制的增大耦合性”
但继承实现对变化的封装表示还不能完全模拟现实世界中的变化。现实世界中的变化不但要存在变化这种概念，更重要的是要确实存在变化这种过程。既然OO是描述现实世界的，因此在OO里面在利用继承封装表示变化（概念）后，接下来要进行的就是实现变化。实现变化需要从语言角度设计一种机制去实现，于是出现了多态，即让父引用指向子引用（其实单就多态机制和客观也非常相似，长辈把提交给自己的工作交给不同的晚辈，例如师傅和徒弟的关系等等）
这样多态动态地实现了变化，实现本身就是一种封装。大规模问题中的规模是指问题空间中具体问题的参与者，参与者（对象）越多，关系越多，关系在面向过程中的体现就是过程对职责的封装，因此参与者越多，职责越多，过程也就越多，从这个角度来说，面向过程设计方法本身无法降低问题的复杂度。同时高复杂度极易导致高耦合性（这里的极易基本可以说是必然的，任何人在面对大规模问题的时候都不可能做到条理有序），例如过程之间调用本身就是一种造成高耦合性的可能。因此，面向对象的设计只能无限制增大耦合性。
“因此，面向对象的设计只能无限制增大耦合性。”你说的是面向过程吧？另外能讲讲面向对象是怎么巧妙的解决耦合性的呢？用多态？
其实oo可以应用到好多地方。
这是人类分析问题，解决问题，归纳问题的方法。
有了oo我们不管用c,pacal或者java多可以很好的处理现实中的问题！