說心裡話，站在一個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不正是擅長樹的表達嗎？干嘛不給他們結合結合？
唉，操作性的東西，能想的能寫的實在不多，對吧？希望接下來的幾章，能激蕩起腦力才是。
