一个
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 如此设计的考量。
我给了自己十五天的时间,不知够否掌握一门语言?我选择了 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 和多重继承没有选择外,我想是没人愿意用它的。
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 和多重继承没有选择外,我想是没人愿意用它的。
。
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 。虽有点意犹未尽,但作为初学的我,也该是知足了。
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 的使用者,都是看中众多的 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) 所有,欢迎各网站转载。转载时请保持原文完整并保留版权信息。