CnPack Forum » CnVCL 组件包 » 能否讲述经验?


2004-8-30 08:35 QQJH
能否讲述经验?

能否讲讲研究VCL源代码的经验?

2004-8-30 10:42 zjy
分析VCL源代码也是有很多层面的,在不同的学习阶段看同样的代码也会有不同的体会,下面简单谈谈我的一些经验:

1、一开始阅读VCL代码,最直观的感受是代码的规范性,VCL的代码是非常清晰、简洁、易读、高效的,几乎找不到一行多余的代码。虽然代码量大,注释少,但还是比较容易理解。阅读VCL代码,让我养成了不管写任何代码都要一丝不苟的习惯。

2、代码实现的技巧和对VCL的深入理解。VCL的代码毕竟是最优秀的Delphi大师千锤百炼的成果,对程序语言本身的运用以及数据结构、算法设计等方面的实现,对我们都有着极大的参考价值。虽然有些代码一时不容易读懂,特别是涉及到其它领域知识的部分(如设计模式),不过多读多用就会慢慢理解。分析VCL的实现机理,对我们在开发中编写有效的代码也非常有帮助,可以避免走弯路。

3、整个VCL体系结构的设计思想。前面的阅读让我们“知其然”,再往后就是分析“其所以然”。为什么Borland的工程师要这样来设计VCL?VCL是怎样一步一步演化来的?如果是我来设计,我会怎样开发自己的组件库?如果有时间,也可以看看介绍VCL体系的书籍,如李维的《Inside VCL》等,带着自己思考的结果和疑问来看书,收获更大。

4、知识和智慧源于思考,有了前面的经验和自己的想法就可以去行动,编写一些有趣的控件,加深对VCL组件的认识和理解。也可以写一些文章总结自己的思想,与其它人交流扩展自己的知识面等。写文章其实是非常有益的工作,既可锻练自己的文字表达能力,又可锻练内容组织和思维能力,还可与别人交流经验,一举多得,呵呵。

另外,CnPack 有一个邮件列表讨论组,也可以在这里面与大家一起讨论,详见:
[url]http://bbs.cnvcl.org/viewthread.php?tid=225[/url]

2004-8-30 20:13 Passion
我们网站的主页上有几篇讨论记录,不少是关于VCL阅读过程中的心得的,可以瞧瞧。

2004-8-30 20:14 Passion
在“原创文档”里头,不过不多,就两三篇。
[url]http://www.cnvcl.org/showlist.php?id=30[/url]

2004-8-31 20:29 Passion
转贴一下邮件列表中Leeon的心得。

有关阅读vcl的经验,我曾经给老罗说过一些。这里发过来吧。本来主要是说提高架构能力的:
看Vcl好结合基础知识和以往开发的知识配合才会产生自己的想法。


说架构经验:


架构优势首先建立在大代码量上。小代码量的,建立架构的时间浪费了开发周期。

其次是在企业级的重用开发上,在一个软件适用领域,不管怎么做项目,都脱不开这个领域的一些特征。总结一些特征,就发挥了FramWork的优势了。我现在做的工作也正是这个。前提是企业级的,需要讲项目成本,讲研发周期,项目制作周期的。个人软件或许不会这么重视。

提高方法总结:架构的优势就是可扩展和可重用,在做小项目可重用可以不考虑。在这两条的前提下有两点必须。

一、对以往项目的总结,就像老罗说的那些,10万代码量只说明一个时段的经验总结。没有一哪来二?或许以后把前面的代码完全摒弃,但是这些经验的总结会成为高效架构的一个大优势。总结自己的经验还远远不够,总结他人的会有更多想法提高。开源软件的用处很大。

又要提一下我现在的工作,原来公司的那个架构已经不适用了,技术总监辞职了,现在我来担任基础架构的设计。总结他的一些想法,然后扩展我的想法也是我的经验。现在是个学习的好机会。:〉

二、学习好的架构技术,我说的是诸如《设计模式》《敏捷软件开发》之类的经验总结书。设计模式这本书并不厚,但说的东西太多。然后是《重构》这样的书籍,尽管说到重构了,是弥补设计不足的时候,但是知道所不足,才能知道设计的时候怎么高效设计。但这些东西真正用得上,又得带着这些知识来开发。在我的感觉这时候真的是很痛苦,面对好东西不知用在什么地方。不过开发久了,自然而然就用得上了。

使用delphi很幸运,可以看VCL的代码。作为一个非常成功的Framework,窥其九牛一毛就受益匪浅。

总之:一个学习总结,再学习再总结的过程。



读Vcl的经验:


真正理解Vcl还是靠Dreamtheater大哥的指点,尽管大哥对delphi用得很少,vcl也没有我看得多。但是一看就看到点子上。短短一年下来,他给我指的几个要点,让我以前的知识全部串联起来了。就这点,我很感激他。

我的总结,了解一个框架,首先得了解它设计的意图,为什么要这么去设计。然后了解组成的机理。从基础开始。也就是说从根开始,可以说寻根溯源。

经历:那时候我还在宁波,也就是去年这个时候。大哥首先说我,你不真正明白消息处理机制,你怎么理解vcl为什么要这么做?大哥又告诉我,你不了解TObject的机理,怎么真正了解Vcl?他甚至怀疑我没有看过vcl的代码。

唉…… 我浮躁,囫囵吞枣,其实什么都不懂。感叹白用delphi五年。

踏踏实实的用罗云彬的那本书,把消息机制再巩固一遍,作为基础,然后把TObject为什么这么建立。一个基础类是怎么建立的搞明之后。顺序把主干类的定义和技术细节看一遍,持久类TPersistent,然后看组件类TComponent代码,然后是控件类TControl,TWinControl,如何把复杂的消息分工使用。尽管对里面技术细节还不是很理解,但目的已经达到了。再编写控件就不浑浑噩噩的写了,因为我理解了vcl的封装机理。

适时地Inside VCL这本书的出版。我很幸运哦。:〉



谈论有关设计:


其实不管怎么设计,怎么编码。

其实还是那句伟大的话:程序 = 算法 + 数据结构。

比较好的设计就是把这二者协调的好的设计。

所谓的过程化设计、模块化设计、对象化设计在我的实践中认为,

这些东西只不过是不适合某些开发,违背了重复代码的大原则等等,应运而生的东西。

老的汇编和老式的Basic一个大大的流程下来。

随着代码量的增加,算法的增多,Dijkstra老先生在1968年提出了模块化设计。把技术细节提取出来。不要掺杂在一起。

代码量继续增加,许多不同的数据加入进来,为了协调处理不同数据的各种算法,不知道谁提出了对象化设计。把处理同一种类型数据的模块,包括数据本身都看成一个对象。继续把技术细节提取出来。

再怎么设计,只不过更好的改进数据和算法之间的关系,使之思路更清晰,更容易维护,更容易扩展。

对方法的选择。也建立在这基础的基础——数据和算法上。

举个设计模式的例子,设计模式中的策略和模板是两个看上去类似但目的截然相反的模式。而他们的区别就是在数据和算法上,

策略模式是在数据源已定的情况下,算法不确定有多种可能的情况而使用的,派生类定义的不同的算法被称为不同的数据处理“策略”。模板模式与之相反就在各种算法是确定的,而数据源是不定的,而这些定义好的算法就是“模板”,数据源在派生种定义。

设计之初就要把数据摆出来,看看需要的数据有哪些,然后根据具体情况定义合适数据结构,预计处理数据的算法摆出来。根据确定性,不确定性,扩展性等基本特性,然后做出相应的设计。

这就是所谓Designer的工作了。算是自我总结吧。



最后自己的总结,其实也是这一段时间的总结:

  学习的一个很有意思的规律,基础知识掌握到了一定程度,仿佛看一些所谓的“高深”的理论和代码,都是水到渠成的事情。

  VCL,设计之初就是为了windows设计的,而消息机制是里面的核心部分,从TObject就为这个作铺垫了,以次一步步建立起来。

  看Vcl的代码,真正明白TObject的东西,就明白了Vcl一半了,核心是一定要掌握的。设计的源头一般是很难理解的,尽管简单。

  其实Inside vcl也没有真正把TObject的机理介绍清楚。

  了解意图,了解目的,了解手法。

                                                        
                              Cheers Leeon

2004-9-1 09:32 QQJH
Good!

自己摸索就像一只没头苍蝇,撞来撞去的!
    听听几位大侠的言论,会有醍醐灌顶之效!

2004-9-1 21:10 listen
very well

我刚用delphi半年多,由于原来用过其他语言开发,加上delphi的机制所以很快就上手了,同时对delphi感觉非常棒,在听到大家比较vc与delphi的优劣时,心里还是偏向delphi的,心里想就编程语言讲我一定要学好.学精delphi,大家的言论对我进一步学习delphi很有指导性作用,多谢多谢!

2004-9-1 22:06 Passion
贴一下我在邮件列表中罗嗦的话。

Leeon写了这么多,确实是非常宝贵的经验。一般来说VCL代码的开始入门的阅读都是自末向枝再到根的,但这个顺序并非足够平坦。初学者开始VCL代码阅读之旅通常是为了研究某个具体控件的机制,或对某事件某属性的疑问与好奇,从而借着Ctrl加Click来闯入VCL的大门。然而门内的东西繁复无比,知道了一点,不知道两点;知其然,不知所以然。因而放弃的有之,然而更多的,是坚持了下来认真阅读。但如果没找到一个合适的切入点,不能提纲挈领地领会所需要的架构,那么这样的坚持阅读便无异于事倍功半。——不少VCL的阅读经验都是提倡从TObject读起,了解构造/析构的基本机制,再熟悉TPersistent的流化和赋值,熟悉TComponent的父子关系和持久载入,熟悉TControl的可视的抽象和Parent机制,熟悉TWinControl和Windows控件的无缝接合,从而慢慢领悟一些标准可视化控件的机制。但这样从头读起,对于基础较差或急于有点成效的朋友来说,确实是个困难所在。我这里说说我自己的一点小习惯(大道理就不说了):从VCL树的枝节开始往上转悠而基本上能无碍地理解到TComponent,这样的情况对于初学者来说比较少。因而可以在中间截取关键点(类似于checkpoint),比如阅读可视类控件的时候,可以将TWinControl作为目标,一口气理解到TWinControl为止(可以不包括TWinControl)。如果这仍然比较困难,可以再朝下,如读Button的时候以TButtonControl为目标,体会各类Button的共性与抽象的思想,然后可以根据思想再看看TSpeedButton等其他东西。这样从枝节摸起,比较容易有成就感,因此积极性也稍微高点。但要注意的是,这样的“成就”只意味着大头,不意味着小节。各个大头到时候还是得朝上摸索朝根部发展。因此可以继续选Checkpoint,继续递归似的阅读。如果在checkpoint处碰到了困难暂时无法弄懂的时候,可从其他资料中参考有关的信息(比如说TWinControl具有句柄,和Windows控件有着对应关系等等),在头脑中将其“规定”为实现此类功能或拥有此类机制的“黑盒”,从而暂时屏弃其内部实现,先拿它作为一块现成的砖头填到思维的墙壁中再说,等有空的时候,再去砸碎这块砖头研究其粉末。当枝节部分摸索得有一定心得的时候,就可能对checkpoint们的实现更加有兴趣,此时便可对砖头开砸,了解其内涵,从而慢慢到达根。了解根的时候是需要有一定的基础的,否则即使死记硬背了其实现和规矩,也没法在其子类中体会其设计思想,甚至也搞不清它为啥要这样做,所以,总得有个慢慢熟悉的过程。
    另外,一个人的思维没法一直都连贯地跳跃,当你查看某个控件的机制的时候,可能子类不懂,看其父类,父类还不够懂,再跳到爷类(^_^,自创的词),这样即使具有超强的阅读理解能力,等到爷类或爷爷类的时候,也许早把前面读的初衷给忘记了。这样读只适合于“消遣”式的无目的的读,而不适合于抱着问题去寻求答案的方式。另外,VCL是Windows上的Framework,无论怎样封装,它最终还是可以和WindowsAPI和消息机制扯上钩,因此Windows的底层知识对VCL的基类等的了解具有莫大的帮助,如果不了解Windows机制,VCL的阅读寻源还只是浮沙上的别墅,总是不扎实的。

2005-3-17 15:15 swt51cd
经典 听听几位大侠的言论,会有醍醐灌顶之效!

听听几位大侠的言论,会有醍醐灌顶之效!
大侠的言论 精彩
获益非浅
谢谢谢谢

2005-4-10 14:51 flamingo
厚,厚!千万不要用这样深奥的方法去看VCL源代码,或者甚至CnPack源代码,看源代码的最快捷径
是..........先看published段,再看public,基本不看private,偶尔看看protected段。

published段(如果有的话),就是代码的输出输入的根本,它涉及的就是整个代码的精华,非看不可。

public段总是有的,偶尔有些输出输入不容易进入属性段,也会放到这里,这里也需要仔细看明白。

protected段目的是为以后的子孙后代预留一些方法或者一些规范,不为它传宗接代,略过吧。

private段顾名思义就知道关我们什么事呢?它大多是属性段的实现,看明白了属性段,这部分就免了吧。

页: [1]
查看完整版本: 能否讲述经验?


Powered by Discuz! Archiver 5.0.0  © 2001-2006 Comsenz Inc.