从MFC的复杂性谈解决问题的方法

和其它面向对象的编程框架相比较，MFC的复杂性来源于3个方面：1、C++繁琐的语法, 2、MFC功能的广泛性,3、架构的不同,4、命名的语义性太差。

C++繁琐的语法

C++不是一门纯粹的面向对象语言，而是同时具备函数式编程、模板编程、元数据编程、面向对象编程等多种语言范式。这是C++功能的强大之处，也是导致C++复杂性的一个重要原因。

由于历史性的原因(保持兼容性、大量使用C++编写的遗留系统)，和C#、Java以及其它很多脚本语言相比较，C++的语法对程序员不够友好。

性能上的优势并不能够成为C++丑陋语法的借口。

MFC功能的广泛性

和Windows Form、Jsp、Struts、WPF、LINQ、ADO.net……等这些面向对象的开发框架向比较，MFC的功能性更加广泛。例如WPF仅仅是专注于UI层的一套开发框架、LINQ仅仅是为了解决OO与SQL范式的鸿沟,为底层各种数据库模型提供统一的面向对象接口，而MFC则不同。

从软件分层的角度来看，MFC的功能跨越了几乎所有的层。下面是一个简单的MFC与各层次功能对应的列表。



图1

图1只是一个粗略的列表，并未涵盖MFC所有功能。

所以，准确来说，MFC不只是一个框架，而是包很多子框架的一个大的框架。甚至可以说，MFC是一个相当于.Net一样的开发平台。仅仅使用MFC，你就可以在在Windows平台上实现任何类型的功能(UI、业务、数据、网络)。而我们绝大部分开发者平时使用到的也只是MFC的冰山一角，更谈不上精通MFC。

架构的不同

先说说设计模式。

一般来说，优秀的系统架构一般会遵循一些通用的设计原则。比如"开－闭"原则(Open Closed Principal)、里氏代换原则、依赖注入原则等等。而所谓设计模式，即是在特定问题领域遵循上述全部或部分原则的面向对象实现。

和现在流行的各种开发框架相比较，MFC并没有很好的实现设计模式。所以，严格来说，MFC是一个强大的框架，但是却并不是一个优秀的框架。这也导致像“如果你想要使用好MFC，你就必须花很多时间来理解MFC的内部实现机制”这样的问题，这是一种很差的封装。

所以，如果想要使用MFC开发出体系结构清晰、扩展性和灵活性良好的系统，就必须手动实现这些设计模式。MFC所能提供的仅仅只是一堆原始的砖头。

命名的语义性太差

其实这个问题是由上一个问题导致的。因为MFC既然所能提供的仅仅是一堆原始的转头，并没有很好的实现设计模式，这就必然导致对各个MFC类和方法的命名上的困难。

一方面，MFC号称是一个现代的、面向对象的、优秀的开发框架；另一方面，MFC确实不是一个多么优秀的框架实现。

因而MFC类库的命名举棋不定。既想提供系统编程的强大功能，又希望提供简单一致的编程模型，此事古难全。

总而言之，MFC的存在只能说是一种强大的半成品。

任何人，如果希望精通MFC，就像很多人想要精通C++一样，可能注定只是一个梦想。因为MFC的复杂性，你不可能搞定并熟记MFC的每一个角落。

但是是否精通MFC却并不影响你使用MFC编写出优秀的程序。

就像我们使用任何其它编程技术一样，MFC无论多么的强大或者丑陋，但是它确确实实是一项有用的技术。解决问题的关键在于对问题空间的准确透彻的理解，一旦深入理解了所面对的问题，怎样使用手头的各种编程工具去解决它就成为了次要的问题。