簡單性是這個世界上最難獲得的東西：它是經驗的最終界限，也是天才的最終努力目標。——George Sand

 

您已經是一位熟練的Delphi程序員，可以運用Delphi快速地寫出一個漂亮、實用的程序；您熱愛Delphi；她已經成了您工作、學習中不可或缺的一部分。我假設這些都為真，那么您當初選擇Delphi作為自己的首選開發(fā)工具一定有自己的理由或者原因。

至少，我自己是符合以上的所有假設的。現在，我所想和您分享的，正是我選擇Delphi的理由及原因，以及我對Delphi的認識。您可以把我看作一個擁護Delphi的狂熱分子，雖然那樣會讓我感到您把我看得太過膚淺，我并不承認，但是我不介意。因為，我真的熱愛她。

第一次接觸的Delphi的版本是3.0，那時候只不過把它當作Visual Basic一樣的RAD工具來用而已。但是，隨著時間的流逝，Delphi 3、Delphi 4、Delphi 5、Delphi 6以及Kylix，對Delphi的認識也越來越深。它是有著豐富內涵的工具，讓人對她越了解，就越對她迷戀，越感覺離不開她，雖然它也還只是工具。

Pascal是一種講究程序美學的語言——毫無疑問，Pascal代碼是最優(yōu)美的代碼——基于Object Pascal（一種支持面向對象的Pascal語言）的Delphi讓這種美達到了極至。

現在，你可以打開Delphi，選擇“Help”－“About”菜單，出現About窗口后，按住Alt鍵，同時順序鍵入“team”，你看到了什么？是的，Delphi開發(fā)人員名單，讓我們感謝他們制造出如此的更象藝術品的開發(fā)工具吧！

經常可以在各個編程論壇上看到類似這樣的問題：“VB還有沒有前途？”；“Delphi是不是要淘汰了？”；“MFC是不是要被.NET取代了？”……其實，這些問題在被提出的當時，是沒有人能給出答案的。因為一種技術、一個產品的前途，并不完全由其本身所能左右，還與市場需求、出品公司的發(fā)展方向等因素有關。而我們所應該關注的，是否就是這些問題的答案呢？我認為不是。

我們知道，世間萬物由原子組成；千變萬化的程序歸根結底由順序、循環(huán)、分支三種結構構成；無論VC的MFC，還是Delphi的VCL，都是由面向對象技術構建的（暫且不論其面向對象的程度）。當你撥開事物表面的表象后，你看到的，是相同的或近似的本質！而掌握了本質之后，就會發(fā)現表象的表現形式是那么的理所當然。試想，當你能象侯捷（《深入淺出MFC》的作者）那樣把MFC剝得體無完膚，你還會擔心MFC被某某框架所取代嗎？從這個角度來說，對于一名專業(yè)程序員，編程的理念是萬變不離其宗的。發(fā)現問題、分析問題、解決問題的過程是存在著某種模式的，當你掌握了這種模式后，不同的編程語言，不同的開發(fā)環(huán)境對你來說，是有共通之處的。

我認為C++是每個專業(yè)程序員所必須掌握的。當然，并不是說單純學習其語法（甚至可以忽略一些語法的學習），而是通過C++學習面向對象的設計、編程方法。因為C++博大精深，因為C++無所不及。在C++中，你可以學習到面向對象理論的全部，學習之后，你會被C++所改造。因為在面向對象理論中存在的，但有所爭議的特性（比如：多重繼承）在C++中都得到支持。你只有在掌握之后，才可能作出自己的選擇（支持或反對）。在掌握了面向對象的理論之后，無論C++、Object Pascal或是java乃至C#，你會感覺到它們的異曲同工之處。

那是否就是說開發(fā)工具（或許應該稱為集成開發(fā)環(huán)境，不過下文還是按我的習慣，用開發(fā)工具來稱呼）之間除了支持的語言不同外，不存在其他差異了？當然也不是。開發(fā)工具是幫助你實現你的理念的工具，也就是構建在基礎理念上的上層建筑。開發(fā)工具對于你所要實現的理念的支持程度以及對實現過程的簡化程度，就是開發(fā)工具的體貼度了。開發(fā)工具于程序員，猶如兵器于士兵，兵器不順手，未戰(zhàn)先敗一半。

一直很喜歡諾基亞手機的廣告詞：科技以人為本！是的，“人”才是本，工具的使命是輔助人更快、更容易地達到目的。因此，開發(fā)工具也應該以人為本！

作為一名程序員，作為開發(fā)工具的最直接的使用者，我希望我所使用的開發(fā)工具真正是我的伙伴、助手，它能給我?guī)碜杂傻母杏X，讓我自由地在代碼的世界中馳騁，它能遷就我、適應我，而不是相反，給我套上枷鎖！

如今在Windows平臺上，有許許多多的開發(fā)工具可以選擇：Visual C++、Visual Basic、Delphi、C++ Builder、JBuilder……它們基于不同的編程語言、忠于不同的公司的產品理念，從這個角度來說，它們之間的差異是非常大的。

那什么樣的開發(fā)工具才是優(yōu)秀的、體貼的、以人為本的？我的標準是符合以下四點：

1、能夠將要解決的問題簡化，并以某種理念快速實現之

2、不隱藏任何你想知道的細節(jié)

3、可以忽略你所不想知道的細節(jié)

4、主動去適應不同層次的程序員

符合以上四點的開發(fā)工具有嗎？我的答案是：有！那就是Delphi！她將一切化繁為簡，卻從不阻止我尋求真實。你可以在她給你構造的簡化了的VCL的虛擬世界中完成任務。也可以鉆進VCL的世界以探詢她和現實世界（即Windows平臺的真實接口）的映射關系，學習它的Framework的設計。你還可以擴展那個虛擬的VCL世界以適應自己的需要。

我為存在著這樣的開發(fā)工具而感到幸運，更為幸運的是，我可以選擇她，和她一起完成我的工作！（現實中，項目中使用什么編程語言、開發(fā)工具，時常并不是你個人所能左右的，會受很多因素制約。比如：客戶的硬件環(huán)境、操作系統環(huán)境，開發(fā)環(huán)境，開發(fā)工具的成本、許可證等等。因此能選擇自己喜歡的開發(fā)工具進行開發(fā)工作實在是很幸運的了。）

通過C++學習面向對象的理念，用Delphi去解決現實世界的問題，這是我的做法。同時也驗證了那句話：學從難處學，用從易處用。

真正的程序員用C++，聰明的程序員用Delphi。那么，真正聰明的程序員用C++來理解Delphi！

用過很多的主流開發(fā)工具，為什么還是選擇了Delphi？也許是因為沒有深入地去熟悉其它開發(fā)工具吧，但Delphi本身的優(yōu)秀至少是原因之一！Delphi優(yōu)秀在何處？

n         開發(fā)的高效

Delphi是一個RAD（Rapid application Development 快速開發(fā)工具），它有可視化的開發(fā)環(huán)境，當然具有類似功能的開發(fā)工具也不少（如Visual Basic），但Delphi有如下的獨到之處：

1）Delphi是真正面向對象的。其基于OO技術構建的VCL庫中的所有組件都可以被繼承以創(chuàng)建新的組件，包括窗體類TForm。相比之下，ActiveX組件缺乏這種靈活性。

2）Delphi的CodeInsight技術（即代碼自動完成功能）是建立在編譯器信息上的，而VB使用的是類型庫信息，使用編譯器信息的好處是更具靈活性。不過，時常有程序員抱怨Delphi的代碼提示時間太長。其實，我個人感覺是習慣了其速度之后，能體會到一種節(jié)奏的快感。

n         語言的高效

Delphi基于Object Pascal語言。這是一種真正支持面向對象而又優(yōu)雅美觀的語言。其在功能的健全上毫不遜色于各種其它的面向對象的語言，但同時又不貪多，盲目地增加復雜性。使得開發(fā)者運用各種模式進行設計時都能得到完善的支持，實現時卻不用考慮太多語言／編譯器細節(jié)。

n         編譯的高效

可以說，Delphi是Windows平臺上最快的高級語言本地代碼編譯器了。編譯速度快有什么好處呢？快速的編譯器可以讓你頻繁地在修改代碼和編譯運行的狀態(tài)間切換。至少，我自己已經非常習慣了這樣的工作方式：運行程序看一下效果，退出程序修改少量代碼再運行程序。而Delphi的編譯器從來不會讓我有等待的感覺。

n         執(zhí)行的高效

Delphi不但編譯速度快，生成的目標代碼的執(zhí)行效率也非常高。Delphi與C＋＋Builder使用的是同一個后端優(yōu)化器，因此其生成的代碼的效率與優(yōu)秀的C++編譯器生成的代碼相同。

Delphi生成完全本地代碼，因此Delphi編譯結果的可執(zhí)行文件可以被獨立執(zhí)行、分發(fā)（對于“綠色軟件”的開發(fā)，這一點十分重要）。不需要其他運行庫支持。當然，你也可以選擇動態(tài)鏈接編譯，這樣可以大大減小可執(zhí)行文件的長度，不過這種情況下在分發(fā)程序時，必須同時分發(fā)必要的運行庫文件。

n         維護的高效

C++把許多決策權給了程序員，因此功能十分強大，但同時，要用C++寫出出色的面向對象的代碼，就要求程序員具有一定的素質。而Delphi程序員會在一定程度上被限制在VCL提供的框架中（當然，完全可以在Delphi中擺脫VCL編程），相對來說，更容易建立良好設計的代碼。而Visual Basic則根本沒有提供面向對象的編程機制（VB6.0及先前版本都是基于對象，而非面向對象）。代碼框架的優(yōu)良使得軟件維護成本大大降低。

基于以上所有理由，我選擇Delphi！

我們平時都會寫很多代碼，為公司，為自己或者為朋友。有時，為了驗證自己的一個想法，或學習某一個技術，會寫一些試驗性的代碼。這樣的代碼的生命周期很短，基本不需要維護，隨意寫一下就可以。但是，當你真正要完成一個項目的時候，代碼設計就非常重要。因為這樣的代碼是需要長期維護，不斷修改或增強的。設計凌亂的代碼會使得維護非常困難或者根本不可能，修改這樣的代碼意味著產生更多的 bug 或者就是災難。

因此，代碼在被編寫之前，需要先被設計。這里所說的設計并不是指功能設計，而是指程序員在編碼前先對代碼框架的設計，以使得今后代碼更容易被理解、被維護。

經常聽到一種說法：程序員的程序壽命只有35歲。我卻從不相信程序員的壽命只到35歲，也許35歲以后，實現能力（其實就是工匠能力）有下降的可能，而設計能力是隨著經驗的增加不降反升的。這才是最寶貴的。

國外的軟件開發(fā)小組，一般的骨干都是40歲上下的人，那些才是大師級的程序員，而所謂的過了35歲就不能當程序員的程序員根本沒有資格被稱為程序員。

軟件工程要將程序員變成編碼員，變成流水線上的一環(huán)，設計工作由專門的設計師完成（如框架設計師）。也許，分工細化是趨勢，但是，我們是滿足于做編碼員還是希望成長為設計師，取決于我們的眼光及努力。

放開眼光，而不是將自己局限于、沉迷于“實現高手”。實現能力是基礎，有一定的實現能力才可能成長，但是，它只是必要條件，而不是充分的。否則，就象爬到山腰就以為自己到了山頂，停滯不前了。那么，你只可能是編碼員，你的程序壽命也只到35歲。在有了這樣的眼光之后，希望本書可以助您起步。

國內出版的Delphi相關書籍，基本都是講解實現的。本書的書名是《Delphi高手突破》。那么，假設你現在已經是Delphi高手了。所以本書不會涉及太多的實現技巧，雖然也有實例代碼，但重點在于其構架的設計，而并非實現。

至此，您也許已經猜出本書的主題了：如何在Delphi中使用面向對象技術，構建良好設計的代碼。

在我看來，寫代碼是藝術創(chuàng)作。優(yōu)雅的代碼可以自解釋，而不需要過多的注釋。當注釋過多的時候，就該考慮設計是否合理了。寫書應該也是藝術創(chuàng)作，如果能把自己的認識、經驗藝術地告訴讀者，而不需要過多的“注釋”（浪費篇幅的廢話），就非常成功了。我希望自己能做到，至少盡量吧。

我相信，走上編程這條路，對于我來說是必然的。能成為專業(yè)程序員，也是我所夢想并實現了的。但是，Delphi的出現以及被我所認識、熟悉、迷戀并成為工作的一部分，應該說是一個意外的驚喜。