一个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)所有，欢迎各网站转载。转载时请保持原文完整并保留版权信息。
