2011年计算机等级考试二级Delphi学习笔记

　　三 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不正是擅长树的表达吗?干嘛不给他们结合结合?

　　唉，操作性的东西，能想的能写的实在不多，对吧?希望接下来的几章，能激荡起脑力才是。

　　2011计算机等考二级公共基础知识讲义汇总

　　2011年上半年计算机等级考试时间：3月26-30日