說心裏話，站在一個C++程序員的立場，是有那麼一點看不上用Delphi的開發者的。就幾周前，我還撰文維護過C++的尊嚴。種種原因，今天我卻須學習Delphi、熟悉Delphi，不由興起人生無常的感慨。
我給了自己十五天的時間，不知夠否掌握一門語言？我選擇了Marco cantu的《Delphi從入門到精通》及《Delphi高級開發指南》作爲學習用書。第一本書名叫《從入門到精通》，但如果你不熟悉一門OOP語言，那這本書不合適你。對我，則正合適。二書總厚度共一千五百頁，嗯，一天一百頁就差不多了，希望自己能做到吧。
我決定如實記下自己的思考與困惑，做爲自己進軍新領域的記念，也希望能爲後行的同路者提供一點幫助。
一 環境
"工欲善其事，必先利其器"，對開發環境的熟悉是非常重要的。不同於VC的MDI界面，Delphi採用了多個獨立窗體設計。這是否預示Borland更提倡組件間進行對等的交互？我暗暗猜測着。
1.Desktop設置是可以與Project分離的，而且Desktop設置優先於Project設置。
2.To-Do列表無論是用於提醒自己還是別人，都是好工具。
3.AppBrowser感覺上很相似於VC的主界面。也提供了符號提示，Code Completiont等功能。嗯，還有VC所沒有的Class Completion，可以在聲明和實現間雙向自動補完。
4.Project Group的概念，有點像.net平臺中的Solution，不過.net是多語言協作的。
二 語言
Delphi的核心是VCL庫，其基礎是Object Pascal。《從入門到精通》用兩章的篇幅細說"Object",卻隻字沒有提到"Pascal"。嗯，還好，我隱隱記得。
1.Use用於引用外部單元。與頭文件不同，Use沒有傳遞性。
2.Delphi使用引用對象模型，對象變量只持有對象引用，不再持有對象本身，所有對象手動自堆中分配。
3.Delphi的封裝很奇怪，類成員訪問權限的設定，只對單元外部起作用。在單元內，可以自對象外部任意訪問類私有成員。朋友解釋說相當於C++的友元，細想其實差異很大--友誼一定是雙向的嗎？（將Unit方式用作友元，A能訪問B，B一定能訪問A）友誼有傳遞性嗎？（將Unit方式用作友元，A能訪問B，B能訪問C，A一定能訪問C）。在我看來，這和友員的概念是不相容的。希望某天我能明白Delphi如此設計的考量。
4.在聲明對象變量後，Delphi對象的實際生成需調用構造器。構造器是特殊的類方法，自TObject繼承並可重載。不使用關鍵字而用類方法構造對象，我認爲這是單根繼承的特有用法。
5.書中有一段動態創建TButton的例子，使用Creat創建了對象，卻沒用Free顯式的釋放
。我疑心會發生內存泄漏，細細想來，該是由持有TButton的容器TForm來負責釋放，朋友證實了我的想法。Delphi以此避免了手動釋放內存的麻煩。
6.Delphi的關鍵字很煩，長而多，要鍵入的地方也多。好處是能爲編譯器提供更多的信息，用以查錯和加快編譯速度。
7.因着引用對象模型，不再有C++中直接對象訪問無多態，只在指針和引用下多態機制才起作用的問題。
8.用message直接指出方法可以處理的事件，唉，讓我想起OWL時Borland對C++語言的相似擴展，真是懷念。
9.大量使用動態類型轉換，該是Pascal本就具有的特點吧？
10.窗體繼承，好像連控件的屬性都可以繼承呢。
11.很奇怪的設計。有類方法，卻不提供類變量，需用Unit級的變量來模擬。
12.如果我的猜想不錯，控件的Events應該就是"對象方法指針"。
13.極強有力的機制：類引用，可用相同的形式動態建立不同的數據類型。C++中相似的能力，怕要用Builder模式纔行。
14.參數對象按引用傳遞，按引用賦值，只有部分類提供Assign方法複製對像。唉，C++的值語意，好懷念。
15.Finally塊！解決了C++中好些需高度技巧的資源釋放問題。但爲什麼不能和except一起使用？不太明白。
16.屬性和事件？？真是爲VCL量身定製的語言啊。其實屬性和事件並非面向對象的必要元素。
17.我想VCL事件處理的委託模型，該是與JAVA相似的。只是Java的Listener可以處理多
個Listener的存在，Delphi的事件屬性好像只能處理一個吧？不過處理速度上要快多了。
18.a)從TComponent類繼承，b)新構造程序,c)例行的Register,d)安裝。VCL組件創建的方便，真讓人感動。
19.書上說VCL優於ActiveX，因爲ActiveX沒有完全的繼承機制，我不敢苟同。聚合該是先於繼承選用的機制。
20.Interface，醜死了！！我甚至懷疑這是否Hejlsberg的設計。完全像是爲Com支持臨時拼湊的語言成份，與整體毫不協調，像個外來戶。接口本身是強大的東西，但糟糕的設計會讓它的使用成爲一種痛苦。除了COM和多重繼承沒有選擇外，我想是沒人願意用它的。
整個來說，Object pascal給我很深的映象。接下來就該學習VCL了，且看Borland是如何將這種種語言的成份，組裝成爲開發的利器。
三 VCL
《從入門到精通》，作者的安排可真大膽。不先講如何在Form上擺控件，倒自VCL講起。我佩服作者的氣魄，直直的深入到問題的核心，剔筋去肉，先將脈絡端到你的面前。要知道，這有着失去很多讀者的危險。
1.TObject，萬類之源。RTTI信息就放在這裏了，這算是單根單繼承實現上的便利吧。
2.一個細節：TButton.InstanceSize=504！真夠浪費的。算法分析中常講以空間換時間，這該算以空間換宜用性吧。
3.作爲TPersisitent的子類，TComponet擁有流化能力。IDE就用其將屬性寫入DFM文件中。
4.TPersisitent委託TFiler和TStream兩個輔助類來具體實現流化。具體實現中包括自RTTI中讀出子類所有擁有的屬性，使流化對程序員透明。
5.非窗口控件？相信是對效率低的一種補償。
6.Componentsk中包含窗體所有上的控件，即使他們的Parent爲別的組件容器，其Owner也是Form.
7.Owner和Parent,兩個易混淆的概念。我的理解：Owner是對象的持有者，Parent是對象的呈現者。
8.窗體元素沒有進行封裝！帶來訪問的便利性的同時，也留下混亂的隱患，特別在大型工程中。
9.控件位置的座標原點對應Parent的客戶區，這加強了我的信心：Parent是對象的呈現者。
10.Frames，窗體繼承的有力競爭者。其本質是以聚合代替繼承。昨天有朋友提出："我覺得聚合是不可以取代繼承的"。的確，聚合不可能完全代替繼承，但在兩者同時適用的條件下，應該選擇耦合較爲鬆散、封裝更爲完全的聚合。具體到Frames和窗體繼承來說，我感覺在不涉及多態時，是應該選用Frames的。
11.Delphi提供的容器類，與C++的STL相比，從彈性到效率可就差遠了，還容易出現類型安全問題。還好Delphi的RTTI機制強大，可以略補不足。這該是沒有模板機制的副作用：整個的泛型思想都用不上。
其實作者還是很爲初學者着想的：並沒有深入VCL。雖有點意猶未盡，但作爲初學的我，也該是知足了。 四：標準組件
其實很多Delphi的使用者，都是看中衆多的VCL組件支持。有朋友對我前文所說"其實屬性和事件並非面向對象的必要元素"表示不敢苟同，我相信他是混淆面向對象和麪向組件了。在我的記憶中，面向組件是面對對象的擴展，其本質雖仍是面向對象，但爲之添加了衆多的輔助特性，其中就包括屬性（不是C++的"屬性"）和事件。
1.Form的Components，GroupBox的Controls，ListBox的Items，Delphi還真是喜歡用數組容器來表達組織結構。
2.還有sleected數組，ItemEnabled數組，哦，值也是通過Items數組的對應項來存儲的。
3.Drag-Drop。看到書的標題，不由的就想到IDataObject、IDropSource、IDropTarget幾個接口。其實Delphi的拖放要簡單很多。就我的瞭解，本質是一個Drop通知，不像Com會將數據本身包裝好傳送。這該是不需支持跨進程Drag-Drop的原因吧。
4.菜單不再做爲資源出現，呈現給應用程序員的，是其包裝後的TMenuItem和組織成嵌套形式的Items。兩個優點：a)純一，不再有菜單資源需程序員理解。2)在包裝層中括展菜單功能極爲方便，並對程序員透明。爲此，ImageList也進行相應包裝。
5.Action，其實質爲雙向事件轉發：各客戶控件->Action->OnExecute，OnUpdata->Action屬性改變->各客戶控件。
6.Owner-draw，還是定製控件畫出自身？一個兩難的選擇。從一個OO純化論者的角度看，Owner-draw實在是對封裝的一種破壞。定製控件畫出自身，卻又未免勞民傷財，浪費資源。
7.TreeView，樹狀視圖。XML不正是擅長樹的表達嗎？幹嘛不給他們結合結合？
唉，操作性的東西，能想的能寫的實在不多，對吧？希望接下來的幾章，能激盪起腦力纔是。
------------------------------------
E-mail：[email protected]
HomePagewww.hisee.net
QQ：80512698
本文爲Dreamer(Dream_soft)原創，版權歸Dreamer(Dream_soft)所有，歡迎各網站轉載。轉載時請保持原文完整並保留版權信息。