为何要学习MFC？

有些人说，MFC过时了。从某些层面上来讲，确实是这样的。随便在求职网上一搜，招MFC程序员的很少，并且以工控和图像处理为主。工控软件由于底层为与硬件打交道的C语言，所以用与C紧密切合的C++语言的类库MFC来做界面确实很方便。并且工控软件对界面外观也没有什么要求。所以MFC在工控软件领域还是占着一席之地。

还有一个领域我们不能忽略，那就是个人软件、小型软件。在猪八戒之类的威客网上软件开发的栏目搜一搜，可以发现大部分的windows程序开发的需求，威客们都是用MFC或Dephi来开发，当然，还有一些易语言。如果你要开发一款个人用的小软件，MFC是很好的选择。

对于这种个人软件、小型软件，MFC还是有着很多优势的：

1.体积小，静态编译后体积也不大。

2.在各版本的windows上兼容性较好。

3.对windowsAPI的调用较方便。

学习MFC不仅仅要学习用MFC，还要学习MFC的框架设计思想。如果仅仅会用MFC的话，可能在找工作的时候，一旦工作内容离开了MFC，就什么也不会了。MFC作为一个诞生了20年的成熟的框架，其设计思想是很值得我们学习的。粗略读一读MFC源代码就会发现MFC的厉害之处，很多思想都让人很佩服，有时候看完一段源代码后，心里暗自感叹。无法想象MFC在那个连C++的STL都还没出现的年代，就用泛型编程技术写出了CList、CArray、CMap等容器。MFC不仅仅是将面向过程的API封装为面向对象的形式，他还在背后做了很多事情，包括简化一些过程，提高一些稳定性。如果让我把面向过程的windows socket API封装成面向对象的类，我肯定会这样想，嗯，socketAPI几乎每个函数的第一个参数都是SOCKET结构体，这是面向过程的特点，如果要封装为面向对象的类，自然是把这个结构体作为类的成员变量，然后封装socketAPI函数为类的方法，提供大量的默认参数，就OK。实际上并非这样，读一读MFC中CSocket的的源代码，就会发现实际上并非如此简单。MFC的CSocket类里，做了大量的工作，使我们用起来大大的方便了。如果你之前一直用socketAPI来开发网络程序，再来用MFC的CAsyncSocket和CSocket的话，会觉得，太方便了！仔细读一读MFC源码，真的对我们将来编写自己的类、设计自己的框架，有很大帮助！

一个好的程序员，不能只是会用现成类库的方法。

一个好的程序员，应该会封装、会设计类库、会设计框架。

在一个实际的项目中往往是这样的：我们需要开发一个windows平台上的软件，直接用windowsAPI吧，1.太麻烦2.面向过程的代码写的越多越头疼3.可重用性不强。使用现成类库吧，有时候无法满足我们特定的需求。这时候，我们就需要自己动手封装API，自己动手派生现成类库中的类，来添加方法。如果你不了解类库，派生下来后就会发现根本无从下手。很多公司在一些做了很久的项目上，往往都是有自己的类库、自己的框架，并不断的完善和扩展。这也是我们要学习类库、框架设计的原因。