为什么你应该在学习MFC之前学习API编程

爭论

　　很多人到IRC上问”哪个好些，MFC或API？”然后有很多人说”MFC不行”或”API差劲”，有的是因为他们在童年的心理创伤，有的是因为別人这样说．

　　标準的爭议话题有：

·API太难

·MFC太令人困惑

·API写起来太多代码

·MFC太臃肿

·API编程沒有助手

·MFC设计糟糕

·API不是面向对象的

·MFC踢了我的狗

·API抢了我女友

还有很多．．．

我的答案

　　我的观点（虽然不是独创的）就是，你应该用合适的工具来完成合适的工作．

　　首先先来对API和MFC给一个清晰的说明. API是Application Programming Interface的缩写，但是在Windows编程的前提下，就是特指的Windows API，是应用程序与windows系统打交道的最底层接口．驱动当然有更低的层数，和一套不同的调用接口，但对于絕大多数windows开发这不是一个要考虑的问题．MFC是一套类库(Class Library)，是一堆已写好的C++类，用来減少用API编程需要写的代码量．它也向应用程序引入了一种(有爭议地)面向对象的框架，你可以利用这个框架也可以忽略它，一般是初学者使用了它，因为这个框架并m不是针对写一个MP3播放器，IRC客戶端，或是遊戏的．

　　任何一个程序，不管它是用MFC，Delphi，Visual Basic，Perl或是其它的你能想到的什么语言或是Framework所写的，都是建构在API之上的.很多情況下，这种关系是隐藏的，所以你不用跟API直接打交道，运行时和支持的库为你做了这些工作.有些人问道，” MFC可以做什么什么，API可以不?”答案是MFC只能做API能做到的，因为前者建于后者之上.但是自己用API来写就比用已经写好的MFC类需要多得多的代码.

　　那么什么算合适的Framework? 对于初学者来讲，那些刚刚学编程的人，我坚信你应该先用API直到你对Windows应用工作的工作原理比较熟悉，理解消息循环，GDI，控件甚至还有多線程和socket背后的基本机制. 这样你就可以理解所有windows应用程序的基本模块，就可以把这些常识用于MFC，Visual Basic，或你在后面的工作中选择使用的任何Framework.这也是很重要的一点，因为这些其它的Framework并不是支持所有API的功能，因为它们已经支持了很多了，不能夠也不必要支持所有的神秘的细节，有些是大多数人并不会使用的. 这样你就可以在最终要用的时候自己加上去，你不能依赖Framework来为你完成　　这些工作，如果你不理解API 这些工作就很让你头痛.

　　但是，MFC不是更简单些码?一般看来，在它为你做的那些通用的工作上它是比较简单，也減少了你需要实际写的代码量.但是在你不理解你要写的代码时，或是不明白那些代码如何为你工作的时候，更少的代码并不意味著更简单. 一般情況下，初学者用向导生成他们的应用但是不理解生成的大多数代码，就要花一堆的时间来试图弄清楚要在哪里加点代码或是改点什么来完成一个特定的任务.如果你用API或是MFC自己写你的程序，你就会明白所有的这些代码，因为就你把它们放在那里的，你就只会用你清楚的功能.

　　另外一个重要的因素就是大多数刚刚学Win32 API的人还沒有一个很扎实的C++基础.同时来试图理解windows编程和学习C++很可能是一个很让你苦恼的任务.虽然不是可能，但是比起你已经熟悉了C++或是API后来说是要花长得多的时间才有可能有所收获.

所以说起来...

　　结论就是你要先学习API编程直至你很熟悉它了，再开始来试MFC.如果它看起来的确有意义，也可以节省你的时间，那就使用它.

　　然而，有很重要的一点...如果不懂API又在用MFC，还想问点什么问题的话，得到了用API陈述的答案(比如”用WM_CTLCOLORSTATIC消息提供的HDC”)，那你就傻眼了，因为你不知道怎么把API话题翻成MFC，然而自己又陷入了困境，別人也烦你，说你为什么不在用MFC之前学点需要的知识.

　　我个人更喜欢用API编程，因为更适合我，但是如果要我写个数据库的前端或是一个有很多ActiveX控件的程序，我就要严肃地思考一下MFC了，因为它可以帮我节省很多代码，否则我就要自己重新发明一遍了.