苛评VCL: 臃肿的Windows控件
写这一篇还是顶着很大的压力的。相信又有不少人要瞧不过去了。不过本着讲讲设计，无所谓好和坏，只有较好和较坏的差别。我只是从我的角度，尽量去解释为什么不赞同VCL中的设计而已。我们知道VCL封装了Windows的标准控件。这些控件包括：Edit、ListBox、ComoBox。还有一些Win32控件，包括ListView、TreeView等等控件。
所有这些，在VCL中定义为TWinControl，他们都包含Windows分配的句柄Handle。也有自己的绘画句柄HDC，当然了，在VCL中就是Canvas属性。我们现在开始说明VCL是如何实现这些控件的。
正如前面所说的，与其说是实现这些控件，更不如说是“封装”这些控件。因为VCL在实现这些控件的时候，采取的是适配器(Adapter)模式。为什么这么说呢？
Windows已经实现了这些控件的数据存储和界面显示两部分。可是VCL又想将这些现成的实现，融入到VCL架构中。这个时候，使用Adapter模式是最适合的了。当然了，这个适配的过程是艰辛和具有创造性的。
我记得刚学习Delphi的时候有人对比MFC的控件的时候，说Delphi将控件的显示和数据做在了一起，而MFC不是。将程序使用MVC来分层分析，当然是一种办法。但是同样可以使用组件来分析。在面向对象系统中，组件即对象。所以VCL将整个控件的数据和显示封装在一起，也是有一定道理的。
最近和同事们也讨论过VCL的这个架构。在Borland看来，这个选择应该是非常明智的。在我看来，至少有几个理由：
<ol> <div style="text-indent: 21pt;">充分利用了Windows这方面的实现和标准。
页:
[1]