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