《Delphi高手突破》第一章——預覽版 (轉)

《Delphi高手突破》第一章——預覽版 (轉)[@more@]

寫在前面的話：目前，正在寫一本面向熟練員的書，主題是在delphi中使用面向技術構建良好設計的程式。

此書還在寫作過程中，我希望能讓大家先對此書的主題以及語言風格能有一個預先的瞭解。同時，能提出自己的意見。作為作者，我希望這本書能成為國內原創Delphi圖書中的經典之作，未必能成功，但我盡力。

由於以上原因，我不可能將整本書都貼出來（呵呵，那樣就沒人去買了），所以應該不會有後續章節貼在這裡（或許會有一些節選吧）了。

在此，我要感謝那些鼓勵過我、提出過意見的朋友（在csdn的delphi論壇我貼過，得到廣泛的響應，謝謝大家了）。還要感謝一直支援、激勵我的女友——Esan。我所能做的，就是把書寫好，回報大家，我知道，大家（包括我）等好書等的太辛苦了！

章  重新認識Delphi

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

 :namespace prefix = o ns = "urn:schemas--com::office" />

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

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

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

Pascal是一種講究程式美學的語言——毫無疑問，Pascal程式碼是最優美的程式碼——基於 Pascal（一種支援物件導向的Pascal語言）的Delphi讓這種美達到了極至。

現在，你可以開啟Delphi，選擇“Help”－“About”選單，出現About視窗後，按住Alt鍵，同時順序鍵入“team”，你看到了什麼？是的，Delphi開發人員名單，讓我們感謝他們製造出如此的更象藝術品的開發工具吧！

1.1  開發工具“以人為本”論

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

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

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

那是否就是說開發工具（或許應該稱為整合開發環境，不過下文還是按我的習慣，用開發工具來稱呼）之間除了支援的語言不同外，不存在其他差異了？當然也不是。開發工具是幫助你實現你的理念的工具，也就是構建在基礎理念上的上層建築。開發工具對於你所要實現的理念的支援程度以及對實現過程的簡化程度，就是開發工具的體貼度了。開發工具於程式設計師，猶如兵器於士兵，兵器不順手，未戰先敗一半。

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

作為一名程式設計師，作為開發工具的最直接的使用者，我希望我所使用的開發工具真正是我的夥伴、助手，它能給我帶來自由的感覺，讓我自由地在程式碼的世界中馳騁，它能遷就我、適應我，而不是相反，給我套上枷鎖！

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

那什麼樣的開發工具才是優秀的、體貼的、以人為本的？我的標準是符合以下四點：

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

2、不隱藏任何你想知道的細節

3、可以忽略你所不想知道的細節

4、主動去適應不同層次的程式設計師

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

我為存在著這樣的開發工具而感到幸運，更為幸運的是，我可以選擇她，和她一起完成我的工作！（現實中，專案中使用什麼程式語言、開發工具，時常並不是你個人所能左右的，會受很多因素制約。比如：客戶的環境、操作環境，開發環境，開發工具的成本、許可證等等。因此能選擇自己喜歡的開發工具進行開發工作實在是很幸運的了。）

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

真正的程式設計師用C++，聰明的程式設計師用Delphi。那麼，真正聰明的程式設計師用C++來理解Delphi！

1.2  Delphi更多的優勢

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

n  開發的高效

Delphi是一個RAD（Rd Application Development 快速開發工具），它有視覺化的開發環境，當然具有類似功能的開發工具也不少（如Visual Basic），但Delphi有如下的獨到之處：

1）Delphi是真正物件導向的。其基於OO技術構建的VCL庫中的所有都可以被繼承以建立新的元件，包括窗體類TForm。相比之下，元件缺乏這種靈活性。

2）Delphi的CodeInsight技術（即程式碼自動完成功能）是建立在資訊上的，而VB使用的是型別庫資訊，使用編譯器資訊的好處是更具靈活性。不過，時常有程式設計師抱怨Delphi的程式碼提示時間太長。其實，我個人感覺是習慣了其速度之後，能體會到一種節奏的快感。

n  語言的高效

Delphi基於Object Pascal語言。這是一種真正支援物件導向而又優雅美觀的語言。其在功能的健全上毫不遜色於各種其它的物件導向的語言，但同時又不貪多，盲目地增加複雜性。使得開發者運用各種模式進行設計時都能得到完善的支援，實現時卻不用考慮太多語言／編譯器細節。

n  編譯的高效

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

n  的高效

Delphi不但編譯速度快，生成的目的碼的執行也非常高。Delphi與C＋＋Builder使用的是同一個後端器，因此其生成的程式碼的效率與優秀的C++編譯器生成的程式碼相同。

Delphi生成完全原生程式碼，因此Delphi編譯結果的可執行可以被獨立執行、分發（對於“綠色”的開發，這一點十分重要）。不需要其他執行庫支援。當然，你也可以選擇動態連結編譯，這樣可以大大減小可執行檔案的長度，不過這種情況下在分發程式時，必須同時分發必要的執行庫檔案。

n  維護的高效

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

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

1.3  本書主題

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

因此，程式碼在被編寫之前，需要先被設計。這裡所說的設計並不是指功能設計，而是指程式設計師在編碼前先對程式碼框架的設計，以使得今後程式碼更容易被理解、被維護。

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

國外的小組，一般的骨幹都是40歲上下的人，那些才是大師級的程式設計師，而所謂的過了35歲就不能當程式設計師的程式設計師根本沒有資格被稱為程式設計師。

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

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

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

至此，您也許已經猜出本書的主題了：如何在Delphi中使用物件導向技術，構建良好設計的程式碼。

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

1.4  小結

我相信，走上程式設計這條路，對於我來說是必然的。能成為專業程式設計師，也是我所夢想並實現了的。但是，Delphi的出現以及被我所認識、熟悉、迷戀併成為工作的一部分，應該說是一個意外的驚喜。

在此，我所想說的就是，對於自己的堅持，就更堅持一些吧。當你清醒地定位了自己之後，清楚地知道自己所選擇的道路之後，就不用有所疑問、有所顧忌了，堅持走下去。最終雖然未必會成功（當然，每個人對成功的定義是不一樣的），但愛我所愛，無怨無悔！