三 VCL

　　《從入門到精通》，作者的安排可真大膽。不先講如何在Form上擺控件，倒自VCL講起。我佩服作者的氣魄，直直的深入到問題的核心，剔筋去肉，先將脈絡(luò)端到你的面前。要知道，這有著失去很多讀者的危險。

　　1.TObject，萬類之源。RTTI信息就放在這里了，這算是單根單繼承實現(xiàn)上的便利吧。

　　2.一個細節(jié)：TButton.InstanceSize=504!真夠浪費的。算法分析中常講以空間換時間，這該算以空間換宜用性吧。

　　3.作為TPersisitent的子類，TComponet擁有流化能力。IDE就用其將屬性寫入DFM文件中。

　　4.TPersisitent委托TFiler和TStream兩個輔助類來具體實現(xiàn)流化。具體實現(xiàn)中包括自RTTI中讀出子類所有擁有的屬性，使流化對程序員透明。

　　5.非窗口控件?相信是對效率低的一種補償。

　　6.Componentsk中包含窗體所有上的控件，即使他們的Parent為別的組件容器，其Owner也是Form.

　　7.Owner和Parent,兩個易混淆的概念。我的理解：Owner是對象的持有者，Parent是對象的呈現(xiàn)者。

　　8.窗體元素沒有進行封裝!帶來訪問的便利性的同時，也留下混亂的隱患，特別在大型工程中。

　　9.控件位置的坐標(biāo)原點對應(yīng)Parent的客戶區(qū)，這加強了我的信心：Parent是對象的呈現(xiàn)者。

　　10.Frames，窗體繼承的有力競爭者。其本質(zhì)是以聚合代替繼承。昨天有朋友提出：\"我覺得聚合是不可以取代繼承的\"。的確，聚合不可能完全代替繼承，但在兩者同時適用的條件下，應(yīng)該選擇耦合較為松散、封裝更為完全的聚合。具體到Frames和窗體繼承來說，我感覺在不涉及多態(tài)時，是應(yīng)該選用Frames的。

　　11.Delphi提供的容器類，與C++的STL相比，從彈性到效率可就差遠了，還容易出現(xiàn)類型安全問題。還好Delphi的RTTI機制強大，可以略補不足。這該是沒有模板機制的副作用：整個的泛型思想都用不上。

　　其實作者還是很為初學(xué)者著想的：并沒有深入VCL。雖有點意猶未盡，但作為初學(xué)的我，也該是知足了。 四：標(biāo)準(zhǔn)組件

　　其實很多Delphi的使用者，都是看中眾多的VCL組件支持。有朋友對我前文所說\"其實屬性和事件并非面向?qū)ο蟮谋匾�元素\"表示不敢茍同，我相信他是混淆面向?qū)ο蠛兔嫦蚪M件了。在我的記憶中，面向組件是面對對象的擴展，其本質(zhì)雖仍是面向?qū)ο螅�但為之添加了眾多的輔助特性，其中就包括屬性(不是C++的\"屬性\")和事件。

　　1.Form的Components，GroupBox的Controls，ListBox的Items，Delphi還真是喜歡用數(shù)組容器來表達組織結(jié)構(gòu)。

　　2.還有sleected數(shù)組，ItemEnabled數(shù)組，哦，值也是通過Items數(shù)組的對應(yīng)項來存儲的。

　　3.Drag-Drop�？吹綍�的標(biāo)題，不由的就想到IDataObject、IDropSource、IDropTarget幾個接口。其實Delphi的拖放要簡單很多。就我的了解，本質(zhì)是一個Drop通知，不像Com會將數(shù)據(jù)本身包裝好傳送。這該是不需支持跨進程Drag-Drop的原因吧。

　　4.菜單不再做為資源出現(xiàn)，呈現(xiàn)給應(yīng)用程序員的，是其包裝后的TMenuItem和組織成嵌套形式的Items。兩個優(yōu)點：a)純一，不再有菜單資源需程序員理解。2)在包裝層中括展菜單功能極為方便，并對程序員透明。為此，ImageList也進行相應(yīng)包裝。

　　5.Action，其實質(zhì)為雙向事件轉(zhuǎn)發(fā)：各客戶控件->Action->OnExecute，OnUpdata->Action屬性改變->各客戶控件。

　　6.Owner-draw，還是定制控件畫出自身?一個兩難的選擇。從一個OO純化論者的角度看，Owner-draw實在是對封裝的一種破壞。定制控件畫出自身，卻又未免勞民傷財，浪費資源。

　　7.TreeView，樹狀視圖。XML不正是擅長樹的表達嗎?干嘛不給他們結(jié)合結(jié)合?

　　唉，操作性的東西，能想的能寫的實在不多，對吧?希望接下來的幾章，能激蕩起腦力才是。

　　2011計算機等考二級公共基礎(chǔ)知識講義匯總

　　2011年上半年計算機等級考試時間：3月26-30日