| 订阅 | 在线投稿
分享
 
 
当前位置: 王朝网络 >> delphi >> 一个C++程序员的Delphi学习笔记
 

一个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)所有,欢迎各网站转载。转载时请保持原文完整并保留版权信息。
 
 
 
上一篇《在delphi字符中包括单引号(")》
下一篇《金额大写转换》
 
 
 
 
 
 
日版宠物情人插曲《Winding Road》歌词

日版宠物情人2017的插曲,很带节奏感,日语的,女生唱的。 最后听见是在第8集的时候女主手割伤了,然后男主用嘴帮她吸了一下,插曲就出来了。 歌手:Def...

兄弟共妻,我成了他们夜里的美食

老钟家的两个儿子很特别,就是跟其他的人不太一样,魔一般的执着。兄弟俩都到了要结婚的年龄了,不管自家老爹怎么磨破嘴皮子,兄弟俩说不娶就不娶,老父母为兄弟两操碎了心...

如何磨出破洞牛仔裤?牛仔裤怎么剪破洞?

把牛仔裤磨出有线的破洞 1、具体工具就是磨脚石,下面垫一个硬物,然后用磨脚石一直磨一直磨,到把那块磨薄了,用手撕开就好了。出来的洞啊很自然的。需要猫须的话调几...

我就是扫描下图得到了敬业福和爱国福

先来看下敬业福和爱国福 今年春节,支付宝再次推出了“五福红包”活动,表示要“把欠大家的敬业福都还给大家”。 今天该活动正式启动,和去年一样,需要收集“五福”...

冰箱异味产生的原因和臭味去除的方法

有时候我们打开冰箱就会闻到一股异味,冰箱里的这种异味是因为一些物质发出的气味的混合体,闻起来让人恶心。 产生这些异味的主要原因有以下几点。 1、很多人有这种习...

 
 
 
一个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)所有,欢迎各网站转载。转载时请保持原文完整并保留版权信息。
󰈣󰈤
 
 
 
  免责声明:本文仅代表作者个人观点,与王朝网络无关。王朝网络登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述,其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
情人节的清纯女生(9)
情人节的清纯女生(8)
情人节的清纯女生(7)
情人节的清纯女生(6)
山东蓬莱海边组照
一探哲蚌 II
一探哲蚌 III
古长城的一角
 
>>返回首页<<
 
 
 为你推荐
 
 
 
 转载本文
 UBB代码 HTML代码
复制到剪贴板...
 
 热帖排行
 
 
 
 
©2005- 王朝网络 版权所有