Window编程: 再见MFC

Window编程: 再见MFC
    1989年，微软成立一个Application Framework小组，这个小组雄心勃勃，想要统一一个前后台的，跨平台的编程框架。显然，这个野心最后失败了，AF组开发的一个AFX编程框架，最后也仅仅是用在了Windows平台。在Afx编程框架的基础之上，后来有了著名的MFC，为了和VCL竞争。
    AF的巨大野心使得AFX框架变得极其的复杂，充满了令人费解的设计。虽然很多设计最后被证明是毫无意义的，但是为了保持兼容，微软大度的把它们留了下来。于是，一堆叫做Afx......的莫名其妙的函数被留在了MFC类库里面，最为全局函数存在----这真是一一个讽刺，一个类库不得不含有了一堆新的api函数。而这些个函数本身，又根本没有做任何具体的事情，它们只是调用和包装了一下原有的Win32API，把它们变得更加复杂和诡异了! 例如AfxMessageBox似乎原来是想用一个switch语句，来在不同的窗口系统里面，调用相应的MessageBox函数。可是现在，它除了调用了::MessageBox，把当前执行线程的顶层窗口作为HWND函数以外，没有干任何实际的事情。

    再有，AFX为了达到所谓的最大的运行效率，抛弃了委托"容器"运行模块的框架思想(J2ee/.net)，而是结合了VB式的基于组建的编程，以及用了无数的诡异的宏定义去包装Windows的执行流程。它号称，一个最大的好处是，程序员不必写WinMain，不必定义WinProc，不必定义消息处理循环。可是真的当程序员需要搞清楚MFC程序的执行过程的时候，事情变得一团糟。我大概在一个实际工程里面写了数万行的程序以后才基本弄清楚这些诡异的宏都是在干什么。更糟糕的是，如果你想企图修改一下，这个框架给你生成的代码当中的，哪怕是一点点，无数的编译和运行时的错误就此产生了。而且，微软的开发工具，不同的版本之间，产生的这些宏，不能保证是向前向后都兼容的，要是要向另一个开发工具版本移植，基本上就是等着哭吧。
    任何过渡的设计，都不如什么都不设计。
    一个糟糕的框架带来的问题，可能比它试图解决的问题还多。MFC/AFX的问题在于，它太复杂了，把简单的事情弄得很复杂。除了声明一个新的窗口类和定义 WinMain/WinProc这样的重复性的工作被简化了以外，实际上任何MFC函数调用只是对Win32API的重写，MFC没有节约任何开发的时间和复杂度。它是可以让初学Windows编程的人在设计窗口程序的时候有了VB的感觉，但是，它让初学者止步不前。真正需要实现稍微复杂一点的功能，还是 要调用一堆Win32API。可是讲MFC的似乎对于说清楚Win32API没有兴趣----它们总是告诉读者要如何点击鼠标，如何填充框架。
    Windows程序设计，Windows核心编程，就像Unix环境高级编程一样，能把问题说清楚，把道理讲清，而不是把一层层裹脚布包装的类库呈现在别人面前，这些才是最有价值的书籍----讲编程的书，一个良好的编程环境，应该是可以通过键盘，用语言说清楚的。VB有多糟糕，MFC就有多糟糕。java的Swing和C#里面可以用鼠标拖动控件，但是实际上都生成对应的代码流程，而不是一堆被隐含的逻辑。

    ----------------------------------------------------------------------------
    忽然间想起10年前，开始学习VC编程，抱着一本厚厚的VC++技术内幕，开始写自己的最初的小程序。
    很可惜，那个时候周围没有什么人可以讨论，自己的学习陷入了无限的细枝末节的问题当中。很长时间都把UINT写成UNIT，然后非常郁闷，这个东西从书上抄的怎么编译不过去? 为什么非要用LPCSTR，LPCTSTR? 谁告诉我哪些宏定义是为了编译的时候选择ASCII还是Unicode模式因此可以产生不同编码的编译结果? 那本书上会把那些层出不穷的细节讲清楚，使得设计程序的人能真正的关心问题? 那一层一层的宏定义，就算"Go to definition"都搞不明白到底是怎么弄出来的。于是，在无数的细节问题面前，我对它的学习停步了将近2年。直到2年以后，买了一本Windows程序设计，开始用Win32API编程，以前的那些问题，突然就豁然开朗了。1年后，我把VC++技术内幕给卖掉了。在最基本的系统API面前，所有的原理和知识都是明显呈现的，没有隐含的知识和诡异的流程，所谓的内幕，也就是被撤下来的遮羞布，没有什么价值了。
    再见，MFC。你曾经害得我好苦。