//來自<Delphi 5 Developer's Guide>
1.2 Delphi 是什麼
我們常常問這樣的問題：「到底什麼讓D elphi 如此優秀？」和「為什麼和別的程式設計工具相比，我更願意選擇D elphi ？」等等。這些年來，我們對這類問題已經得出了兩種答案，一長一短。短的就是：高效性。要創建Wi ndows 應用程序，使用D elphi 是我們能夠找到的最為簡捷的途徑。當然，有些人(老闆們和未來的客戶們)並不滿足於這個答案。因此，我們必須推出我們的詳細解答，它闡述了使得D elphi 如此有效率的綜合因素。我們把決定一個軟體開發工具效率的因素歸結為以下五點：
• 視覺化開發環境的效能。
• 編譯器的速度和已編譯程式碼的效率。
• 程式語言的功能及其複雜性。
• 資料庫結構的靈活性和可擴展性。
• 框架對設計與使用模式的擴充。
雖然還有許多其他因素應該包括進去，如配置、文件、第三方的支援等，但我們發現這是向人們解釋我們為什麼選擇D elphi 的最確切、最簡單的方式。當然，上述五點也可能包含了一些主觀因素，但關鍵在於：你使用特定工具進行開發時，到底能有多大的效率？如圖1 - 1 所示，對一種工具的各方面性能進行評估量化( 1 到5 之間)，並分別標在圖1 - 1的各條軸線上，最後就能得到一個五邊形。五邊形的面積越大，則這種工具的效率越高。
毋需告訴你我們使用這種方法得到了什麼答案―你自己一試便知！下面讓我們來仔細地看一下D elphi 在這幾方面的表現如何，並把它們和其他Wi ndows 開發工具做一比較。
1.2.1 可視化開發環境
視覺化開發環境通常分為三個組成部分：編輯器、調試器和窗體設計器。和大多數現代RAD (快速應用開發)工具一樣，這三個部分是協同工作的。當你在窗體設計器中工作時，D elphi 在背景會自動為你正在窗體中操縱的控制項產生程式碼。你也可以自己在編輯器中加入程式碼來定義應用程式的行為，同時也可以在同一個編輯器中透過設定斷點和監控點等來調試程式。
總的來說D elphi 的編輯器和其他工具的編輯器類似，但它的C ode I nsight 技術卻省去了許多輸入工作的麻煩。這項技術是建立在編譯器資訊之上的，而不是基於像Visual Basic 等所使用的類型庫，因此應用範圍更廣泛。雖然D elphi 的編輯器也設定了許多不錯的設定選項，但我覺得Visual Studio 的編輯器配置空間更大。在版本5 裡，D elphi 的偵錯器功能終於趕上了Visual Studio 的偵錯器，具備了許多先進的功能，如遠端偵錯、製程關聯、DLL 和套件偵錯、自動本地監控以及CPU 視窗等。 D elphi 還支援在偵錯時隨意放置和停靠視窗並將此狀態儲存為命令的桌面設定。由此，D elphi 的IDE 實現了對調試功能的良好支援。
正如經常在一些整合環境(如VB 和某些J ava 工具)中見到的那樣，一個性能非常完善的調試器的長處就在於：應用程式被調試時能修改它的程式碼，從而改變它的行為。遺憾的是，由於此功能在編譯成本地程式碼時過於複雜而無法實現，故不能為D elphi 所支援。
對RAD 工具(如D elphi 、Visual Basic 、C + + B uilder 和P ower B ilder 等)來說，窗體設計器是一項獨特的功能。一些較經典的開發環境，如VC + +和BC + +，都提供了對話編輯器，但卻沒有將窗體設計器整合到開發流程中。由圖1 - 1 的效率圖可以看出，沒有窗體設計器將會降低開發工具的整體效率。幾年可視的來，D elphi 和Visual Basic 在完善窗體設計器的功能方面展開了激烈的競爭。它們的新版本功能一個比一個強。 D elphi 的窗體設計器的與眾不同之處在於，D elphi 是建立在一個真正物件導向的框架結構基礎之上的。這樣，你對基底類別所做的改變都會傳遞給所有的衍生類別。這裡涉及的一項關鍵技術就是VFI(visual form inheritance)，即可視覺化窗體繼承。 VFI 技術可讓你動態地繼承目前專案或物件庫中的任何其他窗體。一旦基底窗體改變，派生的窗體會立即更新。在第4 章「應用程式框架與設計」中有對此重要功能的詳細解釋。
1.2.2 編譯器的速度和已編譯程式碼的效率
快速的編譯器可以使你逐步遞進地開發軟體，經常地修改源代碼、重新編譯、測試、再修改、再編譯、再測試. . . . . .形成這樣一個良好的開發循環。如果編譯速度很慢，開發者就必須分批地修改程式碼，每次編譯前進行多處修改以適應一個低效率的循環過程。提高運作效率、節約運行時間、產生的二進位程式碼更為短小，其優越性是不言而喻的。
也許P ascal 編譯器最著名的特點就是速度快，而D elphi 正是建立在這種編譯器的基礎之上的。事實上，它可能是針對Wi ndows 的最快的高階語言本機程式碼編譯器。以往速度很慢的C + +編譯器在近年來取得了巨大的進步，增加了連結和各種快取策略，尤其是在Visual C++和C + + B uilder 中。但即便如此，C + +的編譯器還是比D elphi 的慢了幾倍。
編譯速度一定能與運作效率成正比嗎？當然不是。 D elphi 和C + + B uilder 共用同一種編譯器後端，因此產生的程式碼等效於優秀的C + +編譯器產生的程式碼。根據最新的可靠評估標準，Visual C++在許多場合都被認為在編譯速度和產生程式碼長度方面是最有效的，這得益於一些極為有力的最佳化措施。雖然對通常的應用程式開發來說，這些細小的優越性難以被注意到，但如果你正在編寫複雜的計算程式碼，那麼它們就會發揮作用。
Visual Basic 的編譯技術有點特別。在開發過程中，VB 以一種整合的方式運作，而且反應相當敏銳。這種編譯器速度比較慢，產生的可執行程式碼的效率也遠不如D elphi 和C + +工具。
J ava 是另一種有趣的語言。最新的基於J ava 的工具語言JB uilder 和Visual J++自稱其編譯速度能趕
得上D elphi ，但是產生程式碼的執行效率卻不盡人意，因為J ava 是一種整合語言。雖然J ave 在穩步前進，但在大多數場合，其運行速度卻仍與D elphi 和C + +相距甚遠。
1.2.3 程式語言的功能及其複雜性
在旁觀者的眼裡，一種語言的功能和複雜程度是極為重要的，這也是許多爭論的熱點。對這個人來說簡單的東西，對那個人來說可能很難；對這個人來說功能有限的東西，對另一個人來說卻可能是非常完美的。因此，以下幾點僅源自於作者個人的經驗和體會。
從根本上來說，彙編是一種最強的語言。用它你幾乎無所不能。但是，即便是用彙編開發最簡單的應用程序，難度也非常大，還可能一無所獲。不僅如此，要想在一個小組開發環境中保留一段彙編程式碼，不管保留多長時間，有時也是根本不可能的。因為程式碼從一個人傳給另一個人、再到下一個人，設計想法和意圖越來越不明朗，直到程式碼看起來如同天書。因此，我們對彙編的評價很低，雖然它功能很強大，但對幾乎所有的開發者來說都太複雜了。
C + +是另一種極為有力的語言。在它的潛在功能(如預處理器巨集、模板、操作符載入等等)的幫助下，你幾乎可以使用C + +設計你自己的語言。只要合理地使用其豐富的功能選項，就可以開發出簡潔直覺、易於維護的程式碼。然而，問題是，許多的開發者總是濫用這些功能，這就很容易導致重大錯誤。事實上，寫出糟糕的C + +程式碼反轉比寫出好的C + +程式碼更容易。因為這種語言自己不會朝著好的設計方向前進―這由開發者決定。
Object Pascal 和J ava 給我們的感覺很相似，因為它們很好地把握住了複雜性和功能性的平衡。它們都採取了這樣一種途徑，即限制其可用功能以加強開發者的邏輯設計。例如，兩者都避免了完全物件導向但容易被濫用的多重繼承的觀念，而是實作了一個執行多重介面功能的類別。兩者都不支援美觀卻危險的操作符載入。兩者都有一些強大的功能，諸如異常處理、運行期類型資訊( RT TI )和生存期記憶體自管理字串。同時，兩種語言都不是由專門的編委會寫出來的，而是來自於單一組織中對這種語言有著共同理解的的個人或小組。
Visual Basic 最初是為了讓程式設計初學者入門更容易、進步更快而設計的(名字也由此而來)。但作為一種語言，VB 也要不斷地取長補短，這使得它近年來也變得越來越複雜了。為了對開發者隱藏這些細節，VB 仍然保留了一些嚮導以創建複雜的專案。
1.2.4 資料庫結構的靈活性和可擴展性
由於B orland 缺少一種資料庫計劃，因此D elphi 保留了我們認為是所有工具中最靈活的資料庫結構。對於大多數基於本機、客戶/伺服器和ODBC 資料庫平台的應用程式來說，BDE 的功能都非常強大。如果你對此不滿意，可以避開使用BDE 以支援新的本地ADO 元件。如果你沒有裝ADO ，可以自己建立資料存取類別或購買第三方資料存取解決方案。此外，MIDAS 使對資料來源的多層存取更易於實現。 M icrosoft 的工具( ODBC 、OLE DB 或其他)從邏輯上來說趨向於支援M icrosoft 自己的資料庫和資料存取解決方案。
1.2.5 框架對設計與使用模式的擴充
這是一項經常被其他軟體設計工具忽略了的重要功能。 VCL 是D elphi 最重要的組成部分。在設計時操縱元件、創建元件、使用OO (物件導向)技術繼承其他元件的行為，這些能力都是決定D elphi 效率的關鍵因素。在許多場合，編寫VCL 元件都採用固定的OO 設計方法。相較之下，其他基於組件的框架經常過於死板或過於複雜。例如A ctive X 控制項具有和VCL 控制項相同的設計期效能，但卻不能被繼承以建立一個具有其他不同行為的新類別。傳統的類別框架，如OWL 和MFC ，需要你有大量的內部結構知識，而且如果沒有RAD 工具的設計期支持，其功能將會受到抑制。未來能夠與VCL 的功能相媲美的一個工具是Visual J++的WFC ( Windows Foundation Classes)，即Wi ndows 基礎類別。但由於Sun Microsystems 對J ava 問題的訴訟仍懸而未決，Visual J++的前景仍不清楚。