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++的前景還不明確。
