为什么 Java 要采用 C++ 的构造模式而不是 Delphi 的？！(50分)

哈哈ego,这句话的我只能算是虚词吧，毕竟开发不是一个人的事情[]
我见过的最大的系统也都是C++开发，当然，我也没有参与过，我觉得现在的商业系统都喜欢用JAVA，主要还是它需要开发人员所具备的知识要比C++少，这样可以降低人件费。而C++往往出现在需要提供高性能，高质量软件服务的CASE中。例如PS2的游戏等等。
http://www.dogn.net/pic/200308/f7a44b4b893eed3956becee8099c8b7f.JPG
这是我参与的一个项目的界面，它是VC++开发的，基础类作的也相当完备，界面看似
花哨，但所有部件都是纵向基础类提供的支持。现在我们仍然再让这些基础类不断的
完善和坚实，这也是减少bug的最好办法。Delphi应该也可以，但我想方法可能
会有不同。在真正的C++开发圈里，能做这样的东西的人很多，而在Delphi人群中，
可能就找不到几个，也许是因为对控件有依赖感吧。
关于虚拟设备是去年为SEGA作的（http://cyberdisc.zaq.ne.jp/），最底层确实有点夸张了，毕竟用C作驱动最好。但是整个架构还是在C++/C的范畴里走。这也是C++在制作成熟产品时所体现的方便。
尽管如此
我个人现在仍然非常喜欢PASCAL，OBJECT PASCAL也不错，只是BORLAND希望Delphi能够让
使用者尽量忘掉语言，不要让人觉得OP强大，而是让人觉得Delphi强大。这点上，Borland
是很成功的。

争来争去， 又争到古老的问题上了。 delphi vs C++
语言：无论多么强大，多么面向对象，没有应用他的地方，早晚会消亡。
适者生存. D在国内取得成功， 是因为他面向的企业应用， 所以 D在BDE上，在MIDAS ，在 CORBA等数据库引擎和接口上 下了很大功夫
D在国内流行的另一方面原因是： 国内的软件公司往往不注重产品的长期维护和技术积累，
开发力求的是快速， 当然维护也没有去仔细考虑， 所以众多开发者往往选用DELPHI 做
开发， 因为DELPHI 有大量成型控件可以参考借鉴
刚才去逛了一下CSDN ， 看着一堆问题， 感觉很迷茫， 各个板块都在重复着类似的问题
总结起来 就是 API ,数据库 ,网络 ,算法 。 把这几方面做个仔细研究， 这些问题不难理解和回答。
语言只是我们手里的逻辑表达工具， 能否写出好的程序， 要看你对操作系统原理的理解
和手里工具使用的熟练程度。(某人说: 给他个BASIC， 他能写任何程序就是这个意思吧)
当然，不同工具各有自己的擅长面和不足处, 偏爱某种工具是看你是否能接受他的缺点
充分发挥他的长处
面向对象是一种思维逻辑的表达。 勿庸置疑，面向对象方式的编程有利于程序的表达和
维护，更能清晰的表达开发者的思路。 所以各个开发工具制造商都极力的在自己的开发语言中加入面向对象的特性， 不过语言和工具是面向对象的了， 你写出的程序是否面向
对象， 还要看你是否习惯了按对象的逻辑去理解问题 和 诠释问题的解决.

我很遗憾，到处喊人来看这个帖子，本来以为可以看到关于c＋＋和java以及delphi语言异同方面的精彩讨论，结果没想到最后又变成了语言的孰优孰劣之争，我实在是很遗憾。我在别处喊人来看这个帖子，我是这样说的：
－－－－－－－－－－－－－－－－－－－－－－－
主题：看似简单的问题
我对delphi没有研究，不好说，本想单就java说点什么，
却突然发现其实我什么也说不出来，汗颜。
－－－－－－－－－－－－－－－－－－－－－－－
说实话，楼上各位似乎都在op方面有深刻的见解，然而，
我们为什么要纠缠于孰优孰劣呢？直到现在，我看到的，
只有意气之争，却仍然没有看到有人认真的就楼主的问题
作出回答，除了crane的第一次回贴。
难得的好贴，被糟蹋了......

To crane and all 大侠:看来你们都是对编程有深厚功力之人，本人刚出道一年，现在只用delphi（在学着c＃），面向对象编程对我来说只是为了减少重复代码量，加速开发效率。其真正的学问，我真的不懂，不知道大侠门有什么好书或方法可以让我去掌握？现在说哪种语言的优劣，我只从商业的角度去考虑，哪种开发工具可以快速，容易掌握，我就学哪种，由于delphi b/s模式开发不方便，所以我才学c＃去，也可以充实一下自己，让自己可以从多角度去考虑问题。

小猪，我觉得比4年前好多了，虽说有点门户之争的嫌疑，但是其实语言多少是有差别的，特别是用的开发工具多了，总是有这样那样的感受。比如最近我在作一个JAVA的东东，有的时候就比较想用宏来区分Debug和Release但是不行，用C++的时候，总觉得释放这那变量太麻烦了，不如用JAVA。反正有得有失。当然我想对一个开发者的修为来说，最好还是不要想一辈子绑在一个语言上。你比如说如果有人问你想学编程，想用VB来学，你是不是会建议他（她）最好先学习VC,或者JAVA，因为一上手就是VB很可能会让一个人把系统想的过于简单，虽然VB用好了也可以深入系统开发，但是会不会容易发生误导？我想答案是肯定的。Delphi也有同样的问题，但是当然好得多。我也比较同意王寒松所说。

我提醒几点：
1、Java基于smalltalk，借鉴C++。事实上所有的面向对象编程语言都可能看到这两者的身影。
2、VB与Delphi的关系。让我们来想一下，为什么RAD开发工具都不选择C++这种最强大的语
言作为底层语言？这要从RAD三个单词上找答案，作为一种快速开发工具，它必须降低入门
门槛和学习难度，Basic是初学者语言，Pascal在当年是教学程序设计的标准语言，从生产
角度来讲，这两种语言都是差劲的，但微软和Borland针对RAD的特性对它们作了大量的手术
，造成的结果是，从此这种语言专属于它的RAD工具，你看过在VB、VBA以外运用Basic编程
的项目吗？你看过不使用Delphi的Object Pascal程序吗？所以，这两种语言都失去了通用
性而专属于一种工具，它们和通用语言C++、Java的差距是十分明显，偏偏Delphi Fans硬要
把它们提升为同一个高度，并为此争吵不休，以前是C++，现在又是Java，典型的不愿面对
现实，他们甚至不会去认真的读读对Delphi的批评之辞，一切都是完美的。
3、抄袭之说。事实Delphi并没有自身的技术。COM/COM+/DCOM是微软的，CORBA也绝不是
Delphi提出的（要开发CORBA组件，要装一个什么？VisBroker for Java！），现在的.NET
也一样，而XML和UML等技术，微软和Java都用了好多年了，Delphi才刚刚开始支持，每一种
技术都是等别人实现了之后才去跟潮流。为什么？Delphi仅仅是一款工具啊，它怎么可能是
和Java和.NET是一个量级呢？你说Delphi万能，说明你的视野你的知识水平还限于一个很窄
的范围内，你没有开发过许多复杂的应用，至少是企业应用和系统程序你没有涉猎过。OK，
Borland是在宣传事事它都行，比如Web编程它就弄出一个什么WebBroker和WebSnap来，但有
人用吗？对真正搞企业应用的人来说，这些东西形同儿戏。
4、Java和.NET之争。
很明显Java绝不会认为Delphi是它的对手，.NET才是。两年前我一直在困惑，既生瑜，何生
亮，偏偏我又看不清最终谁是瑜，谁是亮，怎么办？回头来看，真是可笑！
厂商宣传它的，你学你的，每个厂商都宣称会战胜对方，事实上这种结果永远不会出现。
.NET注定是跨语言不跨平台，它绝不会去真心的支持UNIX和LINUX，微软的策略永远是图谋
让某样东西只能运行在Windows平台上，比如VJ就是一个很好的例子，微软把Java改得极为
依赖Windows平台，SUN被迫不得不回收许可证（再改下去可就会变成今天的C#的模样了）。
所以.NET的跨平台，绝对只是一个姿态，好比Linux宣称可以在wine中运行Windows程序，
Delphi也宣称可以跨平台一样，一头热，对方不买帐！Delphi程序员玩不转Linux，Linux程序员用Delphi的可谓稀奇，Linux程序员对自动生成的并且自己看不见其运行机制的代码有
一种天然的反感，源于对Windows的反感。作为UNIX和Linux厂商来说，它们绝对会抵制.NET运行在它们的平台上，正如微软要抵制Windows程序运行在UNIX和LINUX平台上一个道理。
而Java永远是跨平台不跨语言。它的触角也永远伸不到.NET的领地，Java宣称可以在IIS上运行JSP，的的确确也有JK和JK2支持，但有人用吗？那么国内为什么还把Java炒得这么热，甚至有盖过.NET的势头？过火了，它的正确位置在“跨平台”上，大企业的UNIX主机很多，那就是它的位置，中小企业用它就有点舍本逐末了，.NET在Windows平台上绝对比Java做得好得多，并不仅仅是因为财力，还因为财力所体现出来的技术。
5、C++的地位。据我所知，一个优秀的C++程序员比优秀的Delphi程序员和Java程序员的工资都高都多，年薪在六到二十万的工程师中，我估计百分之八十是C++工程师。就我本人来说，学术课题是面像识别中的表情跟踪，我简直难以想象除了C++还有那种语言能够开展工作？如果要我用Java或Delphi来作快速傅里叶变换、构造小波函数、进行小波变换，你还不
如杀了我！记得前几年Delphi和VC之争时有人把VC骂得一无是处，然而，就是我们最初级的
课题如图像细化与边缘提取等，Delphi也束手无策（但我们有好些同行是用VC写好了DLL后，再用Delphi写界面）。回头来看年薪六到二十万，是编程高手吗？是。单是编程高手吗？不是！专门知识（行业知识）厉害着呢。如果你只能拿三到四千，想一想除了Delphi你
还会什么？如果你真的居然还会点别的什么，你就不会是Delphi的狂热者了（你会在Delphi
上经历无数挫败）！
7、对设计模式，你也承认它是OOP的精华了，你说Delphi的实现比Java更优秀，请相互用
UML图和代码来说话！设计模式运用不当是有问题，所以才有反模式，专门研究什么情况不
能用模式，要对模式作怎样的更改，但并不意味着设计模式就不行了啊，它只是需要在掌
握了它之后用在它该用的地方。
8、面向对象编程，别老是在哪儿空谈啊！你们懂得这么多，Delphi对面向对象编程又是如
此的优秀，那我们练一练试一试啊？！
比试方法：
1、你画UML图，我根据你的UML图写出Java代码；
2、我画UML图，你根据我的UML图写出Delphi代码。
如何！试一试？

精彩！！，但是好像有点过了[]

To shaga：我的观点只能作为参考。
许多非计算机专业的人，有时候编程水平却非常高（比如hubdog，小猪），我想纠其原因，恐怕是因为他们在学习其他科学的时候养成的良好的学习习惯。重视基础知识的积累。而不是像有时候计算机系的人喜欢找个例子然后照着作，或者是组装硬件的思想，到处找应手的控件，急功近利。或者大谈什么计算机知识生命期1年。
我觉得好的学习方法往往是最简单的方法：
踏踏实实看两年MSDN(我有位同事（大拿）后来可以完全不用看MSDN，都在脑子里了）
踏踏实实用C++或者JAVA等等语言编4年程序或者更长，不用想什么设计模式，不吃亏
怎么能够理解深刻，任何小程序都可以无限扩充，比如原来写二叉树的作业，我同学就
在DOS下模拟了一个全3D空间的操控界面，他现在在UBI。

上面有好多C++的疯狂拥护者.
对Delphi还是用得不够深吧，面向对象Delphi已经很好了。
Delphi和Java没有太多的可比性，它是和C++类似的面向对象和面向过程混合式的语言。
离开了VCL类库一样写程序。我们公司就有自己的一套类库，完全脱离VCL的。类似于KOL类库。

光就楼主的具体问题来说,我觉得c++/java的方式更好,更安全,事实上在delphi中,构造方法的第一句通常就会是inherited,常碰到初学class的人忘记这个导致这样那样的问题,为极少可能用到的一点灵活性并不值得放弃这个.
除构造方法外,在c++/java的其他方法中,用Parentclass类名::,super,都可以达到inherited的效果,为什么构造函数例外,我想c++/java的设计器是考虑过的,几乎没有什么理由不这样做.
个人愚见

To lynu
你说的对。inherited未必就是好，也未必就是不好。
当初构建这门语言的时候那些大师们都有自己的出发点。
就象鸡的尖嘴能在土中寻食，鸭的扁嘴适合在水中过滤鱼虾。不能说谁的就是好的。只是两种新式罢了。

那么这两种方式各有什么优缺点呢？或者各适用于什么情况，当初的设计考虑可能是什么？

james martin:
老婆要买一件衣服， 老公说： 蓝色的好， 严肃又庄重
老婆说： 红色的好， 鲜艳有活力
结果1: 老婆尊重了老公的意见， 家里是老公当家
结果2: 老公尊重了老婆的意见， 因为老婆是最终穿衣服的人
这个世界上很多事是不确定的， 最后的方案往往是由老板或是用户来决定

to 王寒松:
即便如此，我们是否可以猜测一下当时“老板或是用户”的理由。不可能没有理由。
大家可以谈谈这个“颜色”给我们的视觉感受，我感觉c++更自然一些，毕竟胎儿都有一段有尾巴的时间[]

说delphi不是主流的人未必小看了delphi,主流也是看什么主流,说java或.net是开发windows GUI程序的主流,我想现阶段绝对没有人赞同.这方面最多VB可以和delphi放在一起说,但也不能放在一个水平线上比.而windows GUI客户端的应用场合,我想还是有很多的,起码在我们中国大量的什么MIS,MRP,"ERP"系统中,现阶段是有delphi立足之地(又何止啊)
需求决定一切,我想现阶段及可见的一段时间,delphi是有其"需求"的地方.软件,也有各行各业各种各样的软件,那些做大系统的大佬,也不要因为你们做的软件在价值上是人家做的系统的十倍百倍就把别人看得一文不值,有的价值上看起来很小的软件,因为其行业及客户的原因,做起来可能比你的系统还麻烦还复杂,只是特点不一样而已

其实关键是什么样的设计思想。
我见过用delphi写的很优美的类继承，上层的工作都设计并实现，你所做的只是完成很简单的代码，但却实现了非常强大的功能。
用java和c++没有这样好的设计，出来的代码也会平庸甚至丑陋。
所以，语言的高低优劣也许存在，但设计思想却是起了决定作用。

语言的选择会在一定程度上影响设计思想，并且不可忽视。

Delphi 的 VCL 比起 VC的 MFC来说更抽象,MFC则更象API的简单封装。
打个可能不恰当的比方来说，一个是精装修，一个是简单装修(更靠近操作系统).
不过VCL的稳定性和效率确实不如MFC,bug多一些，有一些类在实用中根本效率低得
无法使用.
不过从长远来看,手工的 Coding 早晚要灭亡，现在还是软件业的"手工业时代",不过
早晚要进入大工业生产时代.手工可以作出精美的艺术品，但还是没法子与真正的工业
生产竞争的。
这样看，语言、类库之争意义也就不大了.

to wuliaotd
很感谢wuliaotd的刺激和忠告,同时很遗憾 的告诉你 我也用ROSE,还用ROSEDELPHILINK(谁说ROSE不能生成DELPHI代码)生成类代码框架
看你满口设计模式左一个模式右一个模式怎么好象忘了前面的"设计"两个字,知道OOP OOD OOA的区别吗,知道它们产生的时间顺序吗?
我从不崇拜某种语言和工具(但经常佩服设计者的思想),也从不用工资多少来评价人的能力
(你我可能都不如一个美国的看门人)
,更不会因为某人不会某某工具而鄙视他(盖茨估计也不用DELPHI)
我不打算继续浪费版主的版面讨论哪个工具的OOP更强或是否成功,这些早有公论。
大家还是回到主题上吧。
无知者无畏，还真是这么回事儿。

我有一点机械工程经验，卖弄一下[]:
现在很多机械机构（比如传动机构）都有专门的公司作，工业产品设计工作量大为减轻，但是否机械工程师就不需要了解材料性能呢？事实上，正是我们这些基础工作做的不好，我们的工业产品才那么不如人意，劣质设计和制造比比皆是。
如果把语言比作材料的话，偏差不至于太大。RAD也造就了不少营养不良的三流编码员，我也是其中之一。[]