Why you should learn the API before MFC

转自http://blog.csdn.net/Felomeng/archive/2011/03/11/6239264.aspx写得不错，自己翻译一下，想以后时不时地提醒俺，不要偏离自己的方向

 

很多人来到IRC（互联网多线交谈）咨询“MFC和API，学哪一个更好？”，在他们做项目初期有涉及过MFC或者API，或者其他人在谈论它，所以很多人并不希望去说到底MFC不好还是API差劲的话。

这些议论的基本观点是：

API非常难

MFC让人很困惑

API太多的代码

MFC很复杂

API不是面对对象的

MFC“踢了我的小狗”

API“拐走我的女友”

。。。

我的回答

 

在我看来，说用哪个都没什么意义，关键是选择合适的框架来完成适合的任务。

首先来说下API和MFC分别是什么，API是通用术语，表示应用程序设计接口（Application Programming Interface），而在windows环境下，它特指windows API，它是最底层的交互，处于应用程序和windows操作系统之间。驱动当然更底一层次了，不同的函数调用结合在一起使其井然有序。MFC是个类库，它隶属于C++类，它有很好的代码风格，这样可以减少很多不得不需要用API来做的事情。它采用了面对对象框架来构建应用程序，你可以利用它也可以不用它。因为它没有明确的目的去针对于比如MP3播放器、IRC客户端或者游戏，所以很多初学者很困惑怎样选择。

其实每个程序不管是用MFC、Delphi、Visual Basic、perl或者其他的编程语言或者框架，你都得认识到，它最终还是依赖与API的执行。很多情况下这种交互被隐藏了，所以这些事运行时间和支持库为你做的事，你不能直接地用API。一些人问道“MFC能做这啊那的，API能么？”,答案是MFC能够做的API一样可以做到,因为MFC是建立在API基础之上的。但如果做项目用API将会编写比用MFC类库更多的代码。

那什么才是合适的框架呢？作为初学者，那些刚开始接触编程的人们，我强烈建议先从API学起，直到真正掌握了windows应用程序的工作原理，并理解了所有的基本架构、消息机制、GDI（图形设备接口）、控制机制、多线程和sockets。这样你将会理解所有windows应用架构的基本原理，并可以用这些知识去用MFC、Visual Basic、或者其它的你选择的体系框架。非常重要的一点是其它的框架并没有提供所有API能提供的东西，这是因为API提供了相当多的功能，而其它框架不需要支持那些很罕见的用户从来不用的功能。所以当你需要这些功能时你应该自己加入这些API，你不能依赖与框架去做这些事情，如果你还不理解API这将会是件很繁琐困难的事情。

这样看来时不时MFC更容易些呢？一般看来它在处理常规的任务时确实更容易些，因为它减少了大量的需要本应该自己构建的代码。然而，越少的代码并不意味着更简单，如果你不理解那些你应该自己写的代码，就得去了解那些代码是如何支持你的实际工作的。初学者通常地用向导去开始应用程序，但却不懂大部分代码的含义。当你从头开始编程，不管是用API或者MFC，那时你将真正理解所有的机制因为那些你自己放在那的代码，而且你也仅仅会用那些你已经理解的特性。

另一个重要的方面是很多刚开始学win 32 API的朋友并没有很好的C++功底。试图尝试去理解用MFC来windows编程，并同时学习C++时间相当庞大的任务。而且它几乎不可能完成的，它将比那些已经拥有C++技术或者理解API的人要花费更久的时间去达到生产的水平。

 

总结

归根结底，我任务初学者应该先学API直到觉得自己已经理解它了，然后再去尝试了解MFC。如果这样看起来能让你有点编程的感觉并且节约了时间，就一定要尝试一下。

举个例子，如果你在没有了解API的时候，用MFC来进行你的项目，你会寻求些帮助，这些答案是如果你开始先学API就会解决的，你会问“啊？”因为你不懂怎么从API过度到MFC的机制，当然也就不会自行完成了。那时你会陷入困惑并且人们会对你的工作感到灰心，因为那些东西是你本来在用MFC之前就应该会的。

我个人更喜欢用API工作，对我来说真的舒适。但如果我计划写前端数据库，或者为主机设置的插件控制，我将会用MFC，因为它真的节省了很多那些我应该去重写的代码