在前面的話：目前，正在寫一本針對delphi熟練程式設計師的書，主題是在delphi中使用物件導向程式設計技術來建構良好設計的程式。
此書還在寫作過程中，希望能讓大家先對這本書的主題以及語言風格能有預先的了解。同時，能提出自己的意見。身為作者，我希望這本書能成為國內原創Delphi圖書中的經典之作，未必能成功，但我盡力。
由於以上原因，我不可能將整本書都貼出來（呵呵，那樣就沒人去買了），所以應該不會有後續章節貼在這裡（或許會有一些節選吧）了。
在此，我要感謝那些鼓勵過我、提出過意見的朋友（在csdn的delphi論壇我貼過，得到廣泛的回應，謝謝大家了）。也要感謝一直支持、激勵我的女友——Esan。我所能做的，就是把書寫好，回報大家，我知道，大家（包括我）等好書等的太辛苦了！
第1章重新認識Delphi
簡單性是這個世界上最難獲得的：它是經驗的最終界限，也是天才的最終努力目標。 ——George Sand您已經是一位熟練的Delphi程式設計師，可以運用Delphi快速地寫出一個漂亮、實用的程式；您熱愛Delphi；她已經成了您工作、學習中不可或缺的一部分。我假設這些都為真，那麼您當初選擇Delphi作為自己的首選開發工具一定有自己的理由或原因。至少，我自己是符合以上的所有假設的。現在，我所想和您分享的，正是我選擇Delphi的理由及原因，以及我對Delphi的認知。您可以把我看作一個擁護Delphi的狂熱分子，雖然那會讓我感到您把我看得太過膚淺，我並不承認，但是我不介意。因為，我真的熱愛她。第一次接觸的Delphi的版本是3.0，那時只不過把它當作Visual Basic一樣的RAD工具來用而已。但是，隨著時間的流逝，Delphi 3、Delphi 4、Delphi 5、Delphi 6以及Kylix，對Delphi的認知也越來越深。它是有著豐富內涵的工具，讓人對她越了解，就越對她迷戀，越覺得離不開她，雖然它也只是工具。 Pascal是一種講究程式美學的語言－毫無疑問，Pascal程式碼是最優美的程式碼－基於Object Pascal（一種支援物件導向的Pascal語言）的Delphi讓這種美達到了極至。現在，你可以開啟Delphi，選擇“Help”－“About”選單，出現About視窗後，按住Alt鍵，同時順序鍵入“team”，你看到了什麼？是的，Delphi開發人員名單，讓我們感謝他們製造出如此的更像藝術品的開發工具吧！
1.1 發展工具「以人為本」論
常常可以在各個程式設計論壇上看到類似這樣的問題：「VB還有沒有前途？」；「Delphi是不是要淘汰了？」；「MFC是不是要被.NET取代了？」…其實，這些問題在被提出的當時，是沒有人能給出答案的。因為一種技術、一個產品的前途，並不完全由其本身所能左右，還與市場需求、出品公司的發展方向等因素有關。而我們所應該關注的，是否就是這些問題的答案呢？我認為不是。我們知道，世間萬物由原子組成；千變萬化的程序歸根究底由順序、循環、分支三種結構構成；無論VC的MFC，或是Delphi的VCL，都是由物件導向技術建構的（暫且不論其物件導向的程度）。當你撥開事物表面的表象後，你看到的，是相同的或近似的本質！而掌握了本質之後，就會發現表象的表現形式是那麼的理所當然。試想，當你能像侯捷（《深入淺出MFC》的作者）那樣把MFC剝得體無完膚，你還會擔心MFC被某某框架所取代嗎？從這個角度來說，對於專業程式設計師，程式設計的概念是萬變不離其宗的。發現問題、分析問題、解決問題的過程是存在著某種模式的，當你掌握了這種模式後，不同的程式語言，不同的開發環境對你來說，是有共通之處的。我認為C++是每個專業程式設計師所必須掌握的。當然，並不是說單純學習其文法（甚至可以忽略一些文法的學習），而是透過C++學習物件導向的設計、程式設計方法。因為C++博大精深，因為C++無所不及。在C++中，你可以學到物件導向理論的全部，學習之後，你會被C++所改造。因為在物件導向理論中存在的，但有所爭議的特性（例如：多重繼承）在C++中都得到支持。你只有在掌握之後，才可能作出自己的選擇（支持或反對）。在掌握了物件導向的理論之後，無論C++、Object Pascal或是java甚至C#，你會感覺到它們的異曲同工之處。那是否就是說開發工具（或許應該稱為整合開發環境，不過下文還是按我的習慣，用開發工具來稱呼）之間除了支援的語言不同外，不存在其他差異了？當然也不是。開發工具是幫助你實現你的理念的工具，也就是建構在基礎理念上的上層建築。開發工具對於你所要實現的理念的支持程度以及對實現過程的簡化程度，就是開發工具的體貼度了。開發工具於程式設計師，猶如兵器於士兵，兵器不順手，未戰先敗一半。一直很喜歡諾基亞手機的廣告詞：科技以人為本！是的，「人」才是本，工具的使命是輔助人更快、更容易達到目的。因此，開發工具也應該以人為本！作為一名程式設計師，作為開發工具的最直接的使用者，我希望我所使用的開發工具真正是我的伙伴、助手，它能給我帶來自由的感覺，讓我自由地在程式碼的世界中馳騁，它能遷就我、適應我，而不是相反，給我套上枷鎖！如今在Windows平台上，有許多的開發工具可以選擇：Visual C++、Visual Basic、Delphi、C++ Builder、JBuilder……它們基於不同的程式語言、忠於不同的公司的產品理念，從這個角度來說，它們之間的差異是非常大的。那什麼樣的開發工具才是優秀的、體貼的、以人為本的？我的標準是符合以下四點：1、能夠將要解決的問題簡化，並以某種理念快速實現之2、不隱藏任何你想知道的細節3、可以忽略你所不想知道的細節4、主動去適應不同層次的程式設計師符合以上四點的開發工具有嗎？我的答案是：有！那就是Delphi！她將一切化繁為簡，卻從不阻止我尋求真實。你可以在她給你建構的簡化了的VCL的虛擬世界中完成任務。也可以鑽進VCL的世界探詢她和現實世界（即Windows平台的真實介面）的映射關係，學習它的Framework的設計。你也可以擴展那個虛擬的VCL世界以適應自己的需要。我為存在著這樣的開發工具而感到幸運，更為幸運的是，我可以選擇她，和她一起完成我的工作！ （現實中，專案中使用什麼程式語言、開發工具，時常並不是你個人所能左右的，會受很多因素制約。例如：客戶的硬體環境、作業系統環境，開發環境，開發工具的成本、許可證等等。同時也驗證了那句話：學從難處學，用從易處用。真正的程式設計師用C++，聰明的程式設計師用Delphi。那麼，真正聰明的程式設計師用C++來理解Delphi！
1.2 Delphi更多的優勢
用過很多的主流開發工具，為什麼還是選擇了Delphi？也許是因為沒有深入去熟悉其它開發工具吧，但Delphi本身的優秀至少是原因之一！ Delphi優秀在何處？ n 開發的高效Delphi是一個RAD（Rapid application Development 快速開發工具），它有可視化的開發環境，當然具有類似功能的開發工具也不少（如Visual Basic），但Delphi有如下的獨到之處：1 ）Delphi是真正物件導向的。其基於OO技術建構的VCL庫中的所有元件都可以繼承以建立新的元件，包括窗體類別TForm。相比之下，ActiveX組件缺乏這種彈性。 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則完全沒有提供物件導向的程式機制（VB6.0及先前版本都是基於對象，而非物件導向）。程式碼框架的優良使得軟體維護成本大大降低。基於以上所有理由，我選擇Delphi！
1.3 本主題
我們平常會寫很多程式碼，為公司，為自己或為朋友。有時，為了驗證自己的一個想法，或學習某一個技術，會寫出一些試驗性的程式碼。這樣的程式碼的生命週期很短，基本上不需要維護，隨意寫一下就可以。但是，當你真正要完成一個專案的時候，程式碼設計就非常重要。因為這樣的程式碼是需要長期維護，不斷修改或增強的。設計凌亂的程式碼會讓維護非常困難或根本不可能，修改這樣的程式碼意味著產生更多的bug 或是災難。因此，程式碼在被編寫之前，需要先被設計。這裡所說的設計並不是指功能設計，而是指程式設計師在編碼前先對程式碼框架的設計，以使得未來程式碼更容易被理解、被維護。常聽到一種說法：程式設計師的程式壽命只有35歲。我卻從不相信程式設計師的壽命只到35歲，也許35歲以後，實現能力（其實就是工匠能力）有下降的可能，而設計能力是隨著經驗的增加不降反升的。這才是最寶貴的。國外的軟體開發小組，一般的骨幹都是40歲上下的人，那些才是大師級的程式設計師，而所謂的過了35歲就不能當程式設計師的程式設計師根本沒有資格被稱為程式設計師。軟體工程要將程式設計師變成編碼員，變成管線上的一環，設計工作由專門的設計師完成（如框架設計師）。也許，分工細化是趨勢，但是，我們是滿足於當程式設計師還是希望成長為設計師，取決於我們的眼光及努力。放開眼光，而不是將自己局限於、沉迷於「實現高手」。實現能力是基礎，有一定的實現能力才可能成長，但是，它只是必要條件，而不是充分的。否則，就像爬到山腰就以為自己到了山頂，停滯不前了。那麼，你只可能是編碼員，你的程式壽命也只到35歲。有了這樣的眼光之後，希望本書能幫助您起步。國內出版的Delphi相關書籍，基本上都是講解實現的。本書的書名是《Delphi高手突破》。那麼，假設你現在已經是Delphi高手了。所以本書不會涉及太多的實作技巧，雖然也有實例程式碼，但重點在於其架構的設計，而並非實作。至此，您或許已經猜出本書的主題了：如何在Delphi中使用物件導向技術，建構良好設計的程式碼。在我看來，寫程式碼是藝術創作。優雅的程式碼可以自解釋，而不需要過多的註解。當註解過多的時候，就該考慮設計是否合理了。寫書應該也是藝術創作，如果能把自己的認知、經驗藝術地告訴讀者，而不需要過多的「註釋」（浪費篇幅的廢話），就非常成功了。我希望自己能做到，至少盡量。
1.4 小結
我相信，走上程式這條路，對我來說是必然的。能成為專業程式設計師，也是我所夢想並實現了的。但是，Delphi的出現以及被我所認識、熟悉、迷戀並成為工作的一部分，應該說是一個意外的驚喜。在此，我所想說的就是，對於自己的堅持，就更堅持一些吧。當你清醒地定位了自己之後，清楚知道自己所選擇的道路之後，就不用有所疑問、有所顧忌了，堅持走下去。最終雖然未必會成功（當然，每個人對成功的定義是不一樣的），但愛我所愛，無怨無悔！
