为什么学习MFC前先学习API?(略译)-CSDN博客

Why you should learn the API before MFC
为什么学习MFC前先学习API?

原文： http://www.winprog.org/tutorial/apivsmfc.html
刘建文略译（ http://blog.csdn.net/keminlau）

The Controversy争论

Too many people come on to IRC and ask "What is better, MFC or API?" and too many people are willing to say "MFC sucks" or "API sucks" either because of traumatic events involving one or the other in early childhood, or because everyone else is saying it.

有很多人都问一个问题：MFC和API都底哪个更好？而有更多的回复是“MFC太烂了”或者“API太烂了”。偏袒的原因多半是因为他们使用二者有过不好的第一印象，心理上“受伤”所留下了阴影；或者只是听到别人的评价，人云亦云。

The standard arguments are:典型的争论点有如下一些：
* API is too hard
* MFC is too confusing
* API is too much code
* MFC is bloated
* API doesn't have wizards
* MFC is badly designed
* API isn't Object Oriented
* MFC kicked my dog
* API stole my girlfriend

And so on...

My Answer我的答案

My opinion, although by no means the only one, is that you should use the right framework for the right job.

我的观点只有一个：那就是为你的工作需要选择合适的框架（即API或MFC）。

First of all a clarification on what the API and MFC are. API is a generic term meaning Application Programming Interface, however in the context of Windows programming, it means specifically the Windows API, which is the lowest level of interaction between applications and the windows operating system. Drivers of course have even lower levels, and different sets of function calls to work with, but for the vast majority of windows development this is not an issue. MFC is a Class Library, it's a bunch of C++ classes that have been written to reduce the amount of work it takes to do certain things with the API. It also introduces an (arguably) Object Oriented framework into the application that you can either take advantage of or ignore, which is what most beginners do since the framework isn't really aimed at writing MP3 players, IRC clients or games.

首先，我们澄清一下什么是 API和MFC。API是“应用编程接口”，它是应用程序与操作系统交互的边界，是相当的“底层”的东西。比API更“底层”当然数驱动程序了，它直接与硬件交互。MFC是一个C++类库，目的是为了降低用API写特定功能的代码量。MFC同时也为应用开发带来了一种面向对象框架，你可以决定是否使用 OO。很多初学者使用OO，因为框架的初衷并不是写MP3播放器、IRC客户端或游戏。

Every program, whether it is written with MFC, Delphi, Visual Basic, perl, or any other wacked out language or framework you can think of, is eventually built upon the API. In many cases this interaction is hidden, so you don't deal directly with the API, the runtime and support libraries do it for you. Some people ask, "MFC can do Blah Blah Blah, can the API?" The answer is that MFC can only do what the API can do, because it's built on top of it. However doing things yourself with the API may take considerably more code than using the pre-written MFC classes.

无论使用什么样的语言或框架写的程序，最终于还是建立在API之上。很多时候，与API交互是被隐藏的，所以你不必直接与API打交道，运行时或代码库会为你效劳。由于MFC是建立在API之上的，所以MFC能做的API也能，反之则不一定了。当然API的灵活性的代价是代码数量巨增。

So what is the right framework? For starters, for people that are just learning to program, I strongly believe that you should work with the API untill you are comfortable with the way windows applications work and you understand all of the basic mechanics behind things like the message loop, GDI, controls, and maybe even multithreading and sockets. This way you will understand the fundamental building blocks of all windows applications, and can apply this common knowledge to MFC, Visual Basic, or whatever other framework you choose to work with later.

因此什么叫合适的框架呢？对于初学者，他们只是学习编程的技能，我强烈建议你一开始学习API的机理，直到对window应用程序的工作原理了如指掌，包括消息循环、GDI、控件、多线程和套接字的基本机理。这种方式能够让你理解windows应用程序的基本构造块的工作原理，从而把这些通用的知识应用到 MFC、VB等种不同的框架代码中去。（kemin:基本构造块（the fundamental building blocks）是应用框架的有机元素，不同的[应用框架]使用不同的基本构造块。要做GUI开发，那么消息循环、GDI、控件、多线程等FBB是必须掌握的，无论你学什么GUI应用框架。）
（kemin:还有，从这里可以看出来，API是通用的，而MFC是特殊的实现；GUI开发的原理，或者GUI开发框架的理论是通用的；MFC、WCL等框架是特殊的实现，我们要学通用的东西。）

It's also important because these other frameworks don't support everything that the API does, simply because it does a whole lot and they can't necessarily support all of the arcane little things that most people won't use. So when you finally do need to use them you need to add it yourself, you can't rely on the framework to do it for you and if you don't understand the API this could be quite the chore.

学习API的另一个重要的原因是框架不支持所有API所支持的功能。原因很简单，框架只封装那些应用需要的常用的功能。封装的代价就是灵活性的下降。

But isn't MFC easier? In a certain sense it's easier in that many common tasks are done for you, thus reducing the amount of code that you need to actually type. However, less code does not mean "easier" when you don't understand the code you DO need to write, or how all of the code that is there to support you actually works. Generally beginners who use the wizards to start there applications have no idea what most of the generated code does, and spend a great deal of time trying to figure out where to add things, or what changes to make to acheive a certain result. If you start your programs from scratch, either in the API or with MFC, then you know where everything is because you put it there, and you will only use features that you understand.

但是，MFC不是更简单吗？从某种意思上说，是的。MFC为你的常见开发工作提供了方便，降低了开发的所需的代码量。不过，代码少了并不意味着“简单”了。你不明白黑箱内部的具体机理，你的能力很受限制的。

Another important factor is that most people that are learing the Win32 API for the first time don't already have a strong base in C++. To try and comprehend windows programming with MFC and learn C++ at the same time can be a monumental task. Although it's not impossible, it will take you considerably longer to become productive than if you already knew either C++ or the API.

第三个从win32 api开始学习编程的重要原因是，它有助于学习C++。公认学习C++是相当困难的，但是如果带有应用性的学习则效果很不错，而且C++与API一并学习是一箭双雕。

So basically...
What it comes down to is that I think you should learn the API untill you feel comfortable with it, and then try out MFC. If it seems like it's making sense to you and saving you time, then by all means use it.

结论是，先学习API直到相当的熟悉然后再学MFC。

However, and this is important... if you work with MFC without understanding the API and then ask for help with something, and the answer you get is stated using the api (such as "Use the HDC provided in the WM_CTLCOLORSTATIC message") and you say "huh?" because you don't know how to translate an API subject into MFC on your own, then you are in trouble and people will get frustrated with you for not learning what you need to know before you try and use MFC.

I personally prefer to work with the API, it just suits me better, but if I were to write a database frontend, or a host for a set of ActiveX controls I would seriously consider using MFC, as it would eliminate a lot of code that I would need to reinvent otherwise.