三 VCL
《從入門到精通》，作者的安排可真大膽。不先講如何在Form上擺控件，倒自VCL講起。我佩服作者的氣魄，直直的深入到問題的核心，剔筋去肉，先將脈絡(luò)端到你的面前。要知道，這有著失去很多讀者的危險(xiǎn)。
1.TObject，萬類之源。RTTI信息就放在這里了，這算是單根單繼承實(shí)現(xiàn)上的便利吧。
2.一個(gè)細(xì)節(jié)：TButton.InstanceSize=504!真夠浪費(fèi)的。算法分析中常講以空間換時(shí)間，這該算以空間換宜用性吧。
3.作為TPersisitent的子類，TComponet擁有流化能力。IDE就用其將屬性寫入DFM文件中。
4.TPersisitent委托TFiler和TStream兩個(gè)輔助類來具體實(shí)現(xiàn)流化。具體實(shí)現(xiàn)中包括自RTTI中讀出子類所有擁有的屬性，使流化對(duì)程序員透明。
5.非窗口控件?相信是對(duì)效率低的一種補(bǔ)償。
6.Componentsk中包含窗體所有上的控件，即使他們的Parent為別的組件容器，其Owner也是Form.
7.Owner和Parent,兩個(gè)易混淆的概念。我的理解：Owner是對(duì)象的持有者，Parent是對(duì)象的呈現(xiàn)者。
8.窗體元素沒有進(jìn)行封裝!帶來訪問的便利性的同時(shí)，也留下混亂的隱患，特別在大型工程中。
9.控件位置的坐標(biāo)原點(diǎn)對(duì)應(yīng)Parent的客戶區(qū)，這加強(qiáng)了我的信心：Parent是對(duì)象的呈現(xiàn)者。
10.Frames，窗體繼承的有力競(jìng)爭(zhēng)者。其本質(zhì)是以聚合代替繼承。昨天有朋友提出：\"我覺得聚合是不可以取代繼承的\"。的確，聚合不可能完全代替繼承，但在兩者同時(shí)適用的條件下，應(yīng)該選擇耦合較為松散、封裝更為完全的聚合。具體到Frames和窗體繼承來說，我感覺在不涉及多態(tài)時(shí)，是應(yīng)該選用Frames的。
11.Delphi提供的容器類，與C++的STL相比，從彈性到效率可就差遠(yuǎn)了，還容易出現(xiàn)類型安全問題。還好Delphi的RTTI機(jī)制強(qiáng)大，可以略補(bǔ)不足。這該是沒有模板機(jī)制的副作用：整個(gè)的泛型思想都用不上。
其實(shí)作者還是很為初學(xué)者著想的：并沒有深入VCL。雖有點(diǎn)意猶未盡，但作為初學(xué)的我，也該是知足了。 四：標(biāo)準(zhǔn)組件
其實(shí)很多Delphi的使用者，都是看中眾多的VCL組件支持。有朋友對(duì)我前文所說\"其實(shí)屬性和事件并非面向?qū)ο蟮谋匾豛"表示不敢茍同，我相信他是混淆面向?qū)ο蠛兔嫦蚪M件了。在我的記憶中，面向組件是面對(duì)對(duì)象的擴(kuò)展，其本質(zhì)雖仍是面向?qū)ο螅珵橹砑恿吮姸嗟妮o助特性，其中就包括屬性(不是C++的\"屬性\")和事件。
1.Form的Components，GroupBox的Controls，ListBox的Items，Delphi還真是喜歡用數(shù)組容器來表達(dá)組織結(jié)構(gòu)。
2.還有sleected數(shù)組，ItemEnabled數(shù)組，哦，值也是通過Items數(shù)組的對(duì)應(yīng)項(xiàng)來存儲(chǔ)的。
3.Drag-Drop�？吹綍臉�(biāo)題，不由的就想到IDataObject、IDropSource、IDropTarget幾個(gè)接口。其實(shí)Delphi的拖放要簡(jiǎn)單很多。就我的了解，本質(zhì)是一個(gè)Drop通知，不像Com會(huì)將數(shù)據(jù)本身包裝好傳送。這該是不需支持跨進(jìn)程Drag-Drop的原因吧。
4.菜單不再做為資源出現(xiàn)，呈現(xiàn)給應(yīng)用程序員的，是其包裝后的TMenuItem和組織成嵌套形式的Items。兩個(gè)優(yōu)點(diǎn)：a)純一，不再有菜單資源需程序員理解。2)在包裝層中括展菜單功能極為方便，并對(duì)程序員透明。為此，ImageList也進(jìn)行相應(yīng)包裝。
5.Action，其實(shí)質(zhì)為雙向事件轉(zhuǎn)發(fā)：各客戶控件->Action->OnExecute，OnUpdata->Action屬性改變->各客戶控件。
6.Owner-draw，還是定制控件畫出自身?一個(gè)兩難的選擇。從一個(gè)OO純化論者的角度看，Owner-draw實(shí)在是對(duì)封裝的一種破壞。定制控件畫出自身，卻又未免勞民傷財(cái)，浪費(fèi)資源。
7.TreeView，樹狀視圖。XML不正是擅長(zhǎng)樹的表達(dá)嗎?干嘛不給他們結(jié)合結(jié)合?
唉，操作性的東西，能想的能寫的實(shí)在不多，對(duì)吧?希望接下來的幾章，能激蕩起腦力才是。
相關(guān)鏈接：| 北京 | 天津 | 上海 | 江蘇 | 山東 |
| 安徽 | 浙江 | 江西 | 福建 | 深圳 |
| 廣東 | 河北 | 湖南 | 廣西 | 河南 |
| 海南 | 湖北 | 四川 | 重慶 | 云南 |
| 貴州 | 西藏 | 新疆 | 陜西 | 山西 |
| 寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
| 黑龍江 | 內(nèi)蒙古 |
