CSDN博客

img Dream_soft

一个C++程序员的Delphi学习笔记(2)

发表于2001/9/19 1:01:00  1715人阅读

一个C++程序员的Delphi学习笔记(2)

三 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
   HomePage:www.hisee.net
   QQ:80512698

   本文为Dreamer(Dream_soft)原创,版权归Dreamer(Dream_soft)所有,欢迎各网站转载。转载时请保持原文完整并保留版权信息。

0 0

相关博文

我的热门文章

img
取 消
img