| 導購 | 订阅 | 在线投稿
分享
 
 
 

一個C++程序員的Delphi學習筆記

來源:互聯網網民  2006-12-17 07:39:06  評論

一個C++程序員的Delphi學習筆記

一個C++程序員的Delphi學習筆記 一個C++程序員的Delphi學習筆記

說心裏話,站在一個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:Dream_soft@263.net

HomePagewww.hisee.net

QQ:80512698

本文爲Dreamer(Dream_soft)原創,版權歸Dreamer(Dream_soft)所有,歡迎各網站轉載。轉載時請保持原文完整並保留版權信息。

 
特别声明:以上内容(如有图片或视频亦包括在内)为网络用户发布,本站仅提供信息存储服务。
 
一個C++程序員的Delphi學習筆記 一個C++程序員的Delphi學習筆記 一個C++程序員的Delphi學習筆記 說心裏話,站在一個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:Dream_soft@263.net HomePagewww.hisee.net QQ:80512698 本文爲Dreamer(Dream_soft)原創,版權歸Dreamer(Dream_soft)所有,歡迎各網站轉載。轉載時請保持原文完整並保留版權信息。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有