1.2 Delphi 是什么 我们经常会问这样的问题：“到底什么使得D e l p h i 如此优秀？”和“为什么和别的编程工具相比，我更愿意选择D e l p h i ？”等等。这些年来，我们对这类问题已经得出了两种答案，一长一短。短的就是：高效性。要创建Wi n d o w s 应用程序，使用D e l p h i 是我们能够找到的最为简捷的途径。当然，有些人(老板们和未来的客户们)并不满足于这个答案。因此，我们必须推出我们的详细解答，它阐述了使得D e l p h i 如此高效的综合因素。我们把决定一个软件开发工具效率的因素归结为以下五点： • 可视化开发环境的性能。 • 编译器的速度和已编译代码的效率。 • 编程语言的功能及其复杂性。 • 数据库结构的灵活性和可扩展性。 • 框架对设计和使用模式的扩充。 虽然还有许多其他因素应该包括进去，如配置、文档、第三方的支持等，但我们已发现这是向人们解释我们为什么选择D e l p h i 的最确切、最简单的方式。当然，上述五点也可能包含了一些主观因素，但关键在于：你使用一种特定工具进行开发时，到底能有多大的效率？如图1 - 1 所示，对一种工具的各方面性能进行评估量化( 1 到5 之间)，并分别标在图1 - 1的各条轴线上，最后就能得到一个五边形。五边形的面积越大，则这种工具的效率越高。
毋需告诉你我们使用这种方法得到了什么答案―你自己一试便知！下面让我们来仔细地看一下D e l p h i 在这几方面的性能如何，并把它们和其他Wi n d o w s 开发工具做一比较。
1.2.1 可视化开发环境 可视化开发环境通常分为三个组成部分：编辑器、调试器和窗体设计器。和大多数现代R A D (快速应用开发)工具一样，这三部分是协同工作的。当你在窗体设计器中工作时，D e l p h i 在后台自动为你正在窗体中操纵的控件生成代码。你还可以自己在编辑器中加入代码来定义应用程序的行为，同时还可以在同一个编辑器中通过设置断点和监控点等来调试程序。
总的来说D e l p h i 的编辑器和其他工具的编辑器类似，但它的C o d e I n s i g h t 技术却省去了许多输入工作的麻烦。这一技术是建立在编译器信息之上的，而不是基于像Visual Basic 等使用的类型库，因此应用范围更广泛。虽然D e l p h i 的编辑器也设置了许多不错的配置选项，但我觉得Visual Studio 的编辑器配置余地更大。在版本5 里，D e l p h i 的调试器功能终于赶上了Visual Studio 的调试器，具备了许多先进的功能，如远程调试、过程关联、D L L 和包调试、自动本地监控以及C P U 窗口等。D e l p h i 还支持在调试时随意放置和停靠窗口并把这一状态保存为命令的桌面设置。由此，D e l p h i 的I D E 实现了对调试功能的良好支持。
正如经常在一些集成环境(如V B 和某些J a v a 工具)中见到的那样，一个性能非常完善的调试器的长处就在于：应用程序被调试时能修改它的代码，从而改变它的行为。遗憾的是，由于这种功能在编译成本地代码时过于复杂而无法实现，故不能为D e l p h i 所支持。 对R A D 工具(如D e l p h i 、Visual Basic 、C + + B u i l d e r 和P o w e r B i l d e r 等)来说，窗体设计器是一项独特的功能。一些更为经典的开发环境，如V C + +和B C + +，都提供了对话编辑器，但却没有将窗体设计器集成到开发流程中。由图1 - 1 的效率图可以看出，没有窗体设计器将会降低开发工具的整体效率。几年可视的来，D e l p h i 和Visual Basic 在完善窗体设计器的功能方面展开了激烈的竞争。它们的新版本功能一个比一个强。D e l p h i 的窗体设计器的与众不同之处在于，D e l p h i 是建立在一个真正面向对象的框架结构基础之上的。这样，你对基类所做的改变都将会传递给所有的派生类。这里涉及的一项关键技术就是VFI(visual form inheritance)，即可视化窗体继承。V F I 技术使你能够动态地继承当前项目或对象库中的任何其他窗体。一旦基窗体发生改变，派生的窗体会立即予以更新。在第4 章“应用程序框架和设计”中有对这一重要功能的详细解释。
也许P a s c a l 编译器最著名的特点就是速度快，而D e l p h i 正是建立在这种编译器的基础之上的。事实上，它可能是针对Wi n d o w s 的最快的高级语言本地代码编译器。以往速度很慢的C + +编译器在近年来取得了很大的进步，增加了链接和各种缓存策略，尤其是在Visual C++和C + + B u i l d e r 中。但即便如此，C + +的编译器还是比D e l p h i 的慢了几倍。
编译速度一定能与运行效率成正比吗？当然不是。D e l p h i 和C + + B u i l d e r 共享同一种编译器后端，因此生成的代码等效于由一个优秀的C + +编译器生成的代码。根据最新的可靠评估标准，Visual C++在许多场合都被认为在编译速度和生成代码长度方面是最有效的，这得益于一些极为有力的优化措施。虽然对通常的应用程序开发来说，这些细小的优越性难以被注意到，但如果你正在编写复杂的计算代码，那么它们就会发挥作用。
Visual Basic 的编译技术有点特别。在开发过程中，V B 以一种集成的方式运作，而且反应相当敏锐。这种编译器速度比较慢，生成的可执行代码的效率也远远不及D e l p h i 和C + +工具。
J a v a 是另一种有趣的语言。最新的基于J a v a 的工具语言J B u i l d e r 和Visual J++自称其编译速度能赶 得上D e l p h i ，但是生成代码的执行效率却不尽人意，因为J a v a 是一种集成语言。虽然J a v e 在稳步地前进，但在大多数场合，其运行速度却仍与D e l p h i 和C + +相距甚远。
C + +是另一种极为有力的语言。在它的潜在功能(如预处理器宏、模板、操作符加载等等)的帮助下，你几乎可以使用C + +设计你自己的语言。只要合理地使用其丰富的功能选项，就可以开发出简洁直观、易于维护的代码。然而，问题是，许多的开发者总滥用这些功能，这就很容易导致发生重大错误。事实上，写出糟糕的C + +代码反倒比写出好的C + +代码更容易。因为这种语言自己不会朝着好的设计方向前进―这由开发者决定。
Object Pascal 和J a v a 给我们的感觉很相似，因为它们很好地把握住了复杂性和功能性的平衡。它们都采取了这样一种途径，即限制其可用功能以加强开发者的逻辑设计。例如，两者都避免了完全面向对象但却容易被滥用的多重继承的观念，而是实现了一个执行多重接口功能的类。两者都不支持美观却危险的操作符加载。两者都有一些强大的功能，诸如异常处理、运行期类型信息( RT T I )和生存期内存自管理字符串。同时，两种语言都不是由专门的编委会写出来的，而是来自于单个组织中对这种语言有着共同理解的的个人或小组。
Visual Basic 最初是为了使编程初学者入门更容易、进步更快而设计的(名字也由此而来)。但是作为一种语言，V B 也要不断地取长补短，这使得它近年来也变得越来越复杂了。为了对开发者隐藏这些细节，V B 仍然保留了一些向导以创建复杂的项目。
1.2.4 数据库结构的灵活性和可扩展性 由于B o r l a n d 缺少一种数据库计划，因此D e l p h i 保留了我们认为是所有工具中最灵活的数据库结构。对大多数基于本地、客户/服务器和O D B C 数据库平台的应用程序来说，B D E 的功能都非常强大。如果你对此不满意，可以避开使用B D E 以支持新的本地A D O 组件。如果你没有装A D O ，可以自己创建数据访问类或者购买第三方数据访问解决方案。此外，M I D A S 使对数据源的多层访问更易于实现。M i c r o s o f t 的工具( O D B C 、OLE DB 或者其他)从逻辑上来说趋向于支持M i c r o s o f t 自己的数据库和数据访问解决方案。
1.2.5 框架对设计和使用模式的扩充 这是一项经常被其他软件设计工具忽略了的重要功能。V C L 是D e l p h i 最重要的组成部分。在设计时操纵组件、创建组件、使用O O (面向对象)技术继承其他组件的行为，这些能力都是决定D e l p h i 效率的关键因素。在许多场合，编写V C L 组件都采用固定的O O 设计方法。相比之下，其他基于组件的框架经常过于死板或过于复杂。比如A c t i v e X 控件具有和V C L 控件相同的设计期性能，但却不能被继承以创建一个具有其他不同行为的新类。传统的类框架，如O W L 和M F C ，需要你有大量的内部结构知识，而且如果没有R A D 工具的设计期支持，其功能将会受到抑制。将来能够与V C L 的功能相媲美的一个工具是Visual J++的W F C ( Windows Foundation Classes)，即Wi n d o w s 基础类。但是由于Sun Microsystems 对J a v a 问题的诉讼仍悬而未决，Visual J++的前景还不明确。
