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

一个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：[email protected]
   HomePage：www.hisee.net
   QQ：80512698

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






文章动态信息：  
人气： 2151 得票数： 16票
对该文的评论

      HGRhgr ( 2001-9-21 11:20:57 )  

qinghou ：
可视化窗体继承在实际中用得很少???
如果在DELPHI中开发大中型系统不用这项技术，哪对我来说肯定是不可想像的。
还是多学点这项技术，你才能认识到DELPHI真正的的精华
 
      Dream_soft ( 2001-9-20 18:12:00 )  

哦，对不起，笔误了，该是"IE中使用的很多ActiveX控件也是windowless的"。
 
      Dream_soft ( 2001-9-20 18:10:19 )  

To ngkai:
   无窗口控件，其目的就是节约资源的使用,其实IE中使用的ActiveX控件也是windowless的。说他出去效率上的考虑，是我表达的太随意了，不好意思。
   至于你所说窗体不引用则无法访问，我个人认为这是变量的作用域问题，与封装无关。
   To DrunkenLion:
   java的白皮书说的很清楚："Java采用C++的语法，smalltalk的语意。"与C++和Object pascal语意是有很大不同的。至于VCL与Java类库的相似性，只是因为JDK类库部分是外包给Borland做的而已。
   To Musicwind:
   谢谢。我犯了想当然的错误，看到[]就把它当成数组了。


 
      3nt ( 2001-9-20 17:49:05 )  

"窗体元素没有进行封装" 这个问题，Marco Cantu有一篇文章专门讲了这个问题，他说：缺省情况下窗体元素放在public中是为了初学者方便....。这篇文章以前在www.delphioop.com上有，现在这个网站无法访问了。
 
      DrunkenLion ( 2001-9-20 17:19:56 )  

学什么，研究什么，把成见撇开，钻进去，等你真正对vcl有心得了，就不会这么说了，呵呵，
什么都一样，
同样，你用学 c++的眼光学java,你永远也学不好， java 出了语法和c++很象以外，其他的简直是天壤之别，呵呵，跟vcl到是特别象，你信吗？

stl你掌握的怎么样，我不知道，你吃透了泛型设计的思想了吗？我看未必，

 
      likespring ( 2001-9-20 16:52:28 )  

good
 
      ngkai ( 2001-9-20 15:38:55 )  

1、窗体元素没有进行封装?
  在delphi中所有窗体元素在不引用这个窗体的情况下不不可访问的并且访问时要加上窗体对象名。
2、可视化窗体的继承，它在delphi中实现是很容易的，手工可以在dfm文件中加，利用ide也可以。
3、owner-draw是为了方便程序员定制界面。一定程度上牺牲了一些资源，但比较起来免去了程序员去进行消息处理或自写组件的麻烦，还是很值的。
4、TTreeView是win32控件，出现在xml之前，要问为什么不结合xml不如问微软吧。其实对xml的支持,delphi6已经有很多很强大的组件(不是可视组件)了。
5.非窗口控件？相信是对效率低的一种补偿?
胡扯八道。比起TWincontrol.它不占资源，是很好的界面元件。如：TLabel,TSpeedButton.
曾经有一个学vc的以为TLabel和vc的Statictext一样有句柄。
最后阁下可能拿一些c++的编程习惯来学delphi。
 
      lufengjuncool ( 2001-9-20 15:22:39 )  

各位大虾：
    小弟我想问一下，学好DELPHI最多能值多少钱呀(月薪)？请教一下!
 
      DrunkenLion ( 2001-9-20 13:37:45 )  

老大，等你把vcl架构的思想理解的深一点的时候，再来贴这种帖子。

各有千秋，各表一枝。

vcl,和java类库，极其想象，这又说名什么呢，
vcl类库是一个纵向的类库，
mfc是一个横向的类库。

建议你多看一些好点的delphi书，:P
 
      Brand1 ( 2001-9-20 11:07:23 )  

对不起，我有几点看法与   Dream_soft  老兄不同，
1.Delphi中的组件跟VB中不一样，Delphi中的组件应该是Delphi的可视化类库，尽管组件与纯粹的类在表象上不一样，但是那只不过是表现形式的不同而已，其实应该算是OWL类库的扩充。组件机制完全满足面向对象的原则。老兄简单的将VCL归到面向组件上去，有一点不合适，应该说VCL是面向对象的扩充和完善，而众所周知，C++和delphi并不是纯粹的面向对象的语言，只有充分使用对象和基本元素都建立类才可以屏蔽掉面向过程留下的缺陷。
2.窗体并不是继承得少了，在Delphi的IDE中，NEW的时候，就可以很轻松的继承已经存在的窗体，不使用窗体的继承不是窗体的不足，反而是继承窗体并不能减少代码的长度，比较好的办法应该是学习MFC尽量将代码和窗体分开来编写，可视化的编程方法并不能带来面向对象的思想，也不能使代码量减少，反而许多Delphi程序员只是使用大量组件进行简单的过程式的编程的直接原因，应该尽量使用非可视的方法编程。这也许是Delphi大行其道，而Borland公司化了很大气力开发和推广的C++ Biuld始终不能打开局面的根本原因所在，应该说VCL并不是Object Pascal的一部分，她只是一个摸板而已。如果你不愿意使用VCL可以改用别的什么类库，或者自己编一个什么类库出来。
3.Frame并不是什么特别的玩意，她不过是一个容器而已，大量使用Frame并不见得会有多大的好处。

 
      Musicwind ( 2001-9-20 10:59:47 )  

“1.Form的Components，GroupBox的Controls，ListBox的Items，Delphi还真是喜欢用数组容器来表达组织结构。

2.还有sleected数组，ItemEnabled数组，哦，值也是通过Items数组的对应项来存储的”

准确的说，应当是列表(TList)而不是数组Array来存储。

“非窗口控件？相信是对效率低的一种补偿。”

此话怎讲？

“7.Owner和Parent,两个易混淆的概念。我的理解：Owner是对象的持有者，Parent是对象的呈现者。

”
Parent是Windows Api中就有的一个概念，Delphi只是借用了一下而已。
 
      Musicwind ( 2001-9-20 10:46:02 )  

"窗体元素没有进行封装！带来访问的便利性的同时，也留下混乱的隐患，特别在大型工程中"
赞同这一点。但是目前IDE的FormDesigner就是基于窗体元素都是Published的。
 
      Dream_soft ( 2001-9-19 18:12:09 )  

to qinghou:
   我所说的窗体元素没有封装，是指窗体的所有组件都可直接自别的窗体和单元访问（除非用特别技巧）。
   Owner-draw,因为绘制代码并没有和控件本身封装在一起，而是由Form持有，这本质上相当于过程程序设计中，用外部代码对数据结构进行操作的方式。所以说破坏了封装。最OO的方法是自控件继承一个子类，将drew的代码放在子类之内，只是实现上的代价往往不能接受，所以才有Owner-draw的方式。
   GP的问题，很希望能早日看到你的文章。
to zhxtmail:
   继承是比聚合更强的形式，可以说聚合所有的功能，都能用继承实现。但因为子类与父类的耦合太强，所以最好用Frames代替继承。当然，这只是我的想当然：）

 
      kingstone ( 2001-9-19 16:02:30 )  

"可视化窗体继承在实际中用得很少" 窗体继承在DELPHI中作用很大.
 
      zhxtmail ( 2001-9-19 15:08:37 )  

哈哈，没说完。是啊，可视化编程中利用继承是很少。不知你们在可视化编程时，面向对象的方法用了多少呢？看书，看资料，是面向对象是有很多好处。怎么用？用了多少？现在给我了一个有力的工具我却不会使用，悲哀。请赐教！ [email protected]
 
      zhxtmail ( 2001-9-19 15:03:42 )  

Frames?觉得很是多余，继承完全可以了，为什么多此一举。
 
      qinghou ( 2001-9-19 14:37:01 )  

老兄功力深厚，令人佩服。
1、窗体元素没有进行封装是什么意思？
2、Frames，说得很中肯。就我所知，可视化窗体继承在实际中用得很少。不过frames好象用得也不多。
3、Owner-draw为何是对封装的一种破坏呢？看你从什么角度去看了。其它的工具对于Owner-draw的处理思想应该也与此类似吧。
4、GP在Delphi中的实现，是我一直在考虑的一个大问题。我不同意“这该是没有模板机制的副作用：整个的泛型思想都用不上”这种观点。照我看，C++中的非单根结构+模板，与Delphi/Java中的单根结构+RTTI，是实现GP的两种完全不同的思路，很难说后者不如前者。但是Delphi中的容器类确实显得很笨拙。这个问题不是三言两语可以说清楚，过几天我可能将自己的思路整理一下，发上来让大家讨论。很希望你这样兼通C++和Delphi的高手能够指教。
目前Delphi最好的参考书，应该是Borland自己的Delphi Develop Guide，D5/D6的完整版光盘上都自带。应该对你很有帮助。如果你没有也可以到这里下载：ftp://book:[email protected]/delphi6doc.rar
 

转自[a]http://www.csdn.net[/a]