ATL的GUI程序设计(前言)

SDK终究不是一个让人舒适的归宿，我想SDK的粉丝们都应该有着深深的体会。哪怕是你的代码增加到1000行，你都会觉得维护这些东西的难度非常之大——臃肿、堆砌、全局、耦合、复用性差——有太多丑陋的词语都可以用在这上面。是的，我的确说过我不喜欢MFC，但是我也同样不能否认用MFC编写的程序结构清楚、分流明晰——当然，如果你不是深入到MFC内部去看的话。举个例子来说，我所编写的进程查看器July的2.11版本就是用SDK编写的（这个版本是开源的），才1000行出头的代码就已经使得我难以驾驭它们了，以致于后来我不止一次地想重写之——我想过用MFC，甚至Delphi的VCL。不过，运行库的限制和庞大的EXE体积还是使我放弃了这些想法。

如果说MFC和VCL是生长在深宫名门的大家闺秀，那么WTL就可以算是一位浪迹天涯的绝色歌女。我在2004年的时候，曾与它不经意地邂逅。精良的设计、轻巧的EXE、无与伦比的效率——如果不是它的兼容性存在问题的话（如果不修改的话，WTL 7.1连它自己附带的某几个sample都无法通过编译），我几乎就要拜倒在它的石榴裙下了。

于是我继续迷茫，这种迷茫一直持续到了2005年我毕业之后。2005年8月的时候，为了研究不借助MFC调用ActiveX控件的技术，我接触了WTL的发端——为开发COM组件而设计的ATL。时至今日我似乎已经无法回忆起当时的景况，只记得一个月之后，用ATL重写的July v2.20就诞生了。

比起大家闺秀和绝色歌女，ATL则更像是一位温柔贤惠的朴实女子。

对症下药

说归说，ATL终究不是万灵之药。它是否适合你，且看你是否已经存在以下病症（当然，我也为你列出了其它可选药物）：

• 看重程序独立性，不喜欢程序运行库。显然，.net和Visual Basic都不适合你。除ATL外，你还可以选择VCL、MFC（静态链接），当然还有WTL。
• 看重程序效率。Visual Basic绝对不适合你。由于VCL与MFC内部会为窗口控件维护对象链，所以可能也不适合你。在这一方面，ATL和WTL会是不错的选择。
• 看重EXE的大小。没的说，VCL和静态链接的MFC不能列入你的选择，ATL和WTL仍是最佳选择。当然，如果你不计较Windows自己捆绑的MFC运行库的话，MFC动态链接也可以。
• 你不得不在没有MFC的Windows环境下编写代码。有这样的环境吗？也许你要问。是的，Smartphone 2003正是这样一个环境。ATL是你最佳的选择，当然你还可以选择.net Compact Framework。

此外，你需要做好准备迎接以下这些使用了ATL以后可能带来的并发症：