三 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不正是擅长树的表达吗？干嘛不给他们结合结合？
唉，操作性的东西，能想的能写的实在不多，对吧？希望接下来的几章，能激荡起脑力才是。
上一页 [1] [2]
责任编辑：小草
