我是荔园微风，作为一名在IT界整整25年的老兵，今天来看一下我们为什么要使用微软的 Application Framework？
虽然Application Framework 并不是新观念，它们却在最近数年才成为 PC 平台上软件开发的主流工具。面向对象语言是具体实现Application Framework 的理想载具，而C++ 编译器在PC平台上的出现与普及终于允许主流PC程序员能够享受Application Framework 带来的利益。
从八十年代早期到九十年代初始，C++大都存在于UNIX 系统和研究人员的工作站中，不在PC 以及商业产品上。C++ 以及其它的面向对象语言（例如 Smalltalk-80）使一些大学和研究计划生产出现今商业化Application Framework 的鼻祖。但是这些早期产品并没有明显区隔出应用程序与 Application Framework 之间的界线。
今天应用软件的功能愈来愈复杂，建造它们的工具亦复如此。Application Framework、Class Library 和GUI toolkits 是三大类型的软件开发工具，这三类工具虽然以不同的技术方式逼近目标，它们却一致追求相同而基本的软件开发关键利益：降低写程序代码所花的精力、加速开发效率、加强可维护性、增加强固性（robustness）、为组合式的软件机能提供杠杆支点。
当我们面临软件工业革命，我们的第一个考虑点是：我的软件开发技术要从哪一个技术面切入？从raw API 还是从高阶一点的工具？如果答案是后者，第二个考虑点是我使用哪一层级的工具？GUI toolkits 还是Class Library 还是 Application Framework？如果答案又是后者，第三个考虑点是我使用哪一套产品？MFC 或 OWL 或 Open Class Library？别认为这是领导者的事情不是工程师的事情，有这种想法你就永远当不成领导者。
Application Framework，Class Library，GUI toolkit
一般而言，Class Library 和 GUI toolkit 比 Application Framework 的规模小，定位也没那么高阶宏观。Class Library 可以定义为一组具备面向对象性质的类，它们使应用程序的某些功能实现起来容易一些，这些功能包括数值运算与数据结构、绘图、内存管理等；这些类可以一片一片毫无瓜葛地并入应用程序内。
请特别注意这个定义中所强调的一片一片毫无瓜葛，而不像 Application Framework 是大伙儿一并加入。因此，你尽可以随意使用 Class Library，它并不会强迫你遵循任何特定的程序架构。Class Library 通常提供的不只是 UI 功能、也包括一般性质的机能，像数据结构的处理、日期与时间的转换等等。
GUI toolkit 提供的服务类似Class Library，但它的程序接口是程序导向而非面向对象。而且它的功能大都集中在图形与 UI 接口上。GUI toolkit 的发展历史早在面向对象语言之前，某些极为成功的产品甚至是以汇编语言（assembly）写成。不要必然地把GUI 联想到Windows，GUI toolkit也有DOS 版本。我用过的Chatter Box 就是 DOS 环境下的 GUI 工具（是一个函数库）。
使用 Application Framework 的最直接原因是，我们受够了日益暴增的 Windows API。把MFC 想象为第四代语言，单单一个类就帮我们做掉原先要以一大堆 APIs 才能完成的事情。
但更深入地想，Application Framework绝不只是为了降低我们花在浩瀚无涯的Windows API 的时间而已；它所带来的面向对象程序设计观念与方法，使我们能够站在一群优秀工程师（MFC 或 OWL 的创造者）的努力心血上，继承其成果而开发自己之所需。同时，因为 Application Framework 特殊的工作类型，整体开发工具更容易制作，也制作的更完美。在我们决定使用 Application Framework 的同时，我们也获得了这些整合性软件开发环境的支持。在软件开发过程中，这些开发工具角色之重要性不亚于 Application Framework 本身。
Application Framework 将成为软件技术中最重要的一环。如果你不知道它是什么，赶快学习它；如果你还没有使用它，赶快开始用。机会之窗不会永远为你打开，在你的竞争者把它关闭之前赶快进入！如果你认为改朝换代还早得很，请注意两件事情。第一，江山什么时候变色可谁也料不准，当你埋首工作时，外面的世界进步尤其飞快；第二，面向对象和Application Framework可不是那么容易学的，花多少时间才能登堂入室可还得凭各人资质和基础呢。
Microsoft Foundation Classes （MFC）
PC 世界里曾经出了三套C++ Application Frameworks。这三套是Microsoft的MFC （ Microsoft Foundation Classes ） ， Borland 的 OWL（ Object WindowLibrary），以及IBM VisualAge C++ 的Open Class Library。至于其它 C++ 编译器厂商如 Watcom、Symantec、Metaware，只是供应集成开发环境（Integraded Development Environment，IDE），其 Application Framework 都是采用微软公司的 MFC。当然，Borland的消失不能不说是一个很大的遗憾。
Delphi（Pascal 语言），依我之见，也称得上是一套 Application Framework。Java 语言本身内建一套标准类库，依我之见，也够得上资格被称为 Application Framework。
Delphi 和Visual Basic，又被称为是一种应用程序快速开发工具（RAD，Rapid Application Development）。它们采用PME（Properties-Method-Event）架构，写程序的过程像是在一张画布上拼凑一个个现成的组件（components）：设定它们的属性（properties）、指定它们应该有所感的外来刺激（events），并决定它们面对此刺激时在预设行为之外的行为（methods）。所有动作都以拖拉、设定数值的方式完成，非常简单。只有在设定组件与组件之间的互动关系时才牵涉到程序代码的写作（这一小段代码也因此成为顺利成功的关键）。
Borland 公司于1997 年三月推出的C++ Builder也属于PME架构，提供一套Visual Component Library（VCL），内有许许多多的组件。因此 C++ Builder 也算得上是一套RAD（应用程序快速开发工具）。
早初，开发Windows应用程序必须使用微软的SDK（Software Development Kit），直接调用Windows API 函数，向Windows 操作系统提出各种要求，例如配置内存、开启窗口、输出图形...。
所谓API（Application Programming Interface），就是开放给应用程序调用的系统功能。
数以千计的Windows APIs，每个看起来都好像比重相若（至少你从手册上看不出来孰轻孰重）。有些APIs 彼此虽有群组关系，却没有相近或组织化的函数名称。星罗棋布，雾列星驰；又似雪球一般愈滚愈多，愈滚愈大。
MFC帮助我们把这些浩繁的APIs，利用面向对象的原理，逻辑地组织起来，使它们具备抽象化、封装化、继承性、多态性、模块化的性质。
1989 年微软公司成立Application Framework 技术团队，名为AFX小组，用以开发C++ 面向对象工具给 Windows 应用程序开发人员使用。
这个小组最初的宪章，根据记载，是要 "utilize the latest in object oriented technology to provide tools and libraries for developers writing the most advanced GUI applications on the market"，其中并未画地自限与Windows 操作系统有关。果然，其第一个原型产品，有自己的窗口系统、自己的绘图系统、自己的对象数据库、乃至于自己的内存管理系统。
当小组成员以此产品开发应用程序，他们发现实在是太复杂，又悖离公司的主流系统Windows太遥远。于是他们修改宪章变成 "deliver the power of object-oriented solutions to programmers to enable them to build world-class Windows based applications in C++." 这差不多正是Windows 3.0 异军崛起的时候。
C++ 是一个复杂的语言，AFX小组预期MFC的用户不可能人人皆为C++ 专家，所以他们并没有采用所有的C++ 高阶性质（例如多重继承）。许多麻烦但几乎一成不变的Windows程序动作都被隐藏在MFC类之中，例如WinMain 、 RegisterClass、Window Procedure 等等等。
虽说这些被隐藏的Windows 程序动作几乎是一成不变的，但它们透露了 Windows 程序的原型奥秘，这也是为什么我要在本书之中锲而不舍地挖出它们的原因。
为了让MFC尽可能地小，尽可能地快，AFX 小组不得不舍弃高度的抽象（导至过多的虚函数），而引进他们自己发明的机制，尝试在面向对象领域中解决 Windows 消息的处理问题。注意，他们并没有改变C++语言本身，也没有扩大语言的功能。他们只是设计了一些令人拍案叫绝的宏，而这些宏背后隐藏着巨大的机制。
了解这些宏（以及它们背后所代表的机制）的意义，以及隐藏在 MFC 类之中的那些足以曝露原型机密的麻烦事儿，正是我认为掌握 MFC 这套 Application Framework的重要手段。
就如同前面那些形而上的定义，MFC 是一组凝聚性强、组织性强的类库。如果你要利用MFC发展你的应用程序，必须同时引用数个必要类，互相搭配支持。图5-3是一个标准的MFC程序外貌。隐藏在精致画面背后更重要的是，就如我在前面说过，对象与对象之间的关系已经存在，消息的流动程序也都已设定。当你要为这个程序设计真正的应用功能，不必在意诸如我如何得知用户按左键？左键按下后我如何启动某一个函数？参数如何传递过去等琐事，只要专注在左键之后真正要做的功能动作就好。
作者简介：荔园微风，1981年生，高级工程师，浙大工学硕士，软件工程项目主管，做过程序员、软件设计师、系统架构师，早期的Windows程序员，Visual Studio忠实用户，C/C++使用者，是一位在计算机界学习、拼搏、奋斗了25年的老将，经历了UNIX时代、桌面WIN32时代、Web应用时代、云计算时代、手机安卓时代、大数据时代、ICT时代、AI深度学习时代、智能机器时代，我不知道未来还会有什么时代，只记得这一路走来，充满着艰辛与收获，愿同大家一起走下去，充满希望的走下去。
