我是荔园微风，作为一名在IT界整整25年的老兵，今天来看一下什么是微软的 Application Framework？

到底什么是 Application Framework？

我当年学习这个的时候也困惑了好久，于是一直在搜索这个概念有没有好的解释，结果整个互联网都没有好的解释，我是很困惑这个事情的，为什么没有高手来写一段。今天我决定专门来写一写这个问题。对于很多初学者来说，在还没有真正掌握任何一套Application Framework的使用之前，就来研究这个真的不是很明智，尤其如果你对面向对象还没有深刻体会的话。但如果你已经看到这里那就看下去，希望对你有帮助。

一、知名杂志的说法

首先我们看看侯捷在《程序员》杂志上的无责任书评中是怎么说的：演化（evolution）永远在进行，但这个世界却不是每天都有革命性（revolution) 的事物发生。动不动宣称自己（或自己的产品）是划时代的革命性的，带来的影响就像时下满街跑的大师一样使我们渐渐无动于衷，因为大师不可能满街跑。 但是Application Framework 的的确确在我们软件界称得上具有革命精神。

什么是Application Framework？Framework这个字眼有组织、框架、体制的意思，Application Framework不仅是一般性的泛称，它其实还是面向对象领域中的一个专有名词。

基本上你可以说，Application Framework是一个完整的程序模型，具备标准应用软件所需的一切基本功能，像是文件存取、打印预览、数据交换......以及这些功能的使用接口（工具栏、状态栏、菜单、对话框）。如果更以术语来说，Application Framework 就是由一整组合作无间的对象架构起来的大模型。喔不不，当它还没有与你的程序产生作用的时候，它还只是有形无体，应该说是一组合作无间的类架构起来的大模型。

这带来什么好处呢？程序员只要带个购物袋到类超级市场采买，随你要买MDI或OLE或ODBC或Printing Preview，回家后就可以轻易拼凑出一个色香味俱全的大餐。

类超级市场就是C++ 类库，以产品而言，在Microsoft 是MFC，在Borland 是OWL，在IBM则是OpenClass。这个类库不只是类库而已，传统的函数库（C Runtime 或 Windows API）乃至于一般类库提供的是生鲜超市中的一条鱼一支葱一颗大白菜，彼此之间没有什么关联，负责当大厨的你必须自己选材自己调理。

能够称得上Application Framework 者，提供的是拼盘（就是那种带回家通通丢下锅就好的那种），依你要的是白菜火锅鱼头拼盘或是麻辣拼盘，菜色带调理包都给你配好。当然这样的拼盘是不能够就地吃的，你得给它加点能量。这能量就是所谓的application object（在 MFC 程序中就是派生自 CWinApp 的一个全局对象）。是这个对象引起了连锁反应（一连串的 'new'），使每一个形（类）有了真正的体（对象)，把应用程序以及 Application Framework 整个带动起来。一切因缘全由是起。

 Application Framework 带来的是，程序模型已经存在，程序员只要依个人需求加料就好：在派生类中改写虚函数，或在派生类中加上新的成员函数。这很像你在拼盘中依个人口味加盐添醋。

由于程序代码的初期规模十分一致（什么样风格的程序应该使用什么类，是一成不变的），而修改程序以符合私人需要的基本动作也很一致（我是指像开辟一个空的骨干函数这种事情)，你动不了 Application Framework 的大架构，也不需要动。这是福利不是约束。

应用程序代码骨干一致化的结果，使优越的软件开发工具如 CASE（Computer Aid Software Engineering）tool 容易开发出来。你的程序代码大架构掌握在 Application Framework 设计者手上，于是他们就有能力制作出整合开发环境（ Integrated Development Environment，IDE）了。这也是为什么 Microsoft、Borland、Symantec、Watcom、IBM 等公司的集成开发环境进步得如此令人咋舌的原因了。

有人说工学院中唯一保有人文气息的只剩建筑系，我总觉得信息系也勉强可以算上。带艺术气息的软件创作行为（我一直是这么认为的）将在 Application Framework 出现后逐渐成为工匠技术，而我们都将只是软件 IC 装配厂里的男工女工。其实也没什么好顾影自怜，功成名就的冠冕从来也不曾落在程序员头上；我们可能像纽约街头的工作者，自认为艺术家，可别人怎么看呢？不得而知！话说回来，把开发软件这件事情从艺术降格到工技，对人类只有好处没有坏处。不是亨利福特，我们又如何能够享受大众化的汽车？或许以后会出现「纯手工精制」的软件，谁感兴趣不得而知，我自己嘛...唔...倒是从来不嫌机器馒头难吃。

如果要三言两语点出 Application Framework 的特质，我会这么说：我们挖出别人早写好的一整套模块（MFC 或 OWL 或 OpenClass）之中的一部分，给个引子（application object）使它们一一具象化动起来，并被允许修改其中某些零件使这程序更符合私人需求，如是而已。

看了以上他说的内容，是不是一下子就明白了，不得不佩服啊。

二、普通程序员的说法

侯捷的这一段话实在已经点出Application Framework的精神。凝聚性强、组织化强的类库就是 Application Framework。一组合作无间的对象，彼此间靠消息的流动而沟通，并且互相调用对方的函数以求完成任务，这就是 Application Framework。对象存在哪里？在MFC中?MFC的各个类只是对象属性（行为）的定义而已，我们不能够说 MFC 中有实际的对象存在。唯有当程序被application object（这是一个派生自 MFC CWinApp 的全局对象）引出，才将我们选用的类一一具象化起来，产生实体并开始动作。

这样子说吧，静态情况下MFC 是一组类库，但在程序运行时期它就生出了一群有活动力的对象组。最重要的一点是，这些对象之间的关系早已建立好，不必程序员操心。好比说当用户按下菜单的【File/Open】项，开文件对话框就会打开；用户选好文件名后，Application Framework 就开始对着你的数据类，唤起一个名为Serialize 的特殊函数。这整个机制都埋好了，你只要把心力放在那个叫作 Serialize 的函数上即可。

选用标准的类，做出来的产品当然就没有什么特色，因为别人的零件和你的相同，做起来的成品也就一样。我指的是用户接口（UI）对象。但你要知道，软件工业发展到现阶段，UI 已经渐渐走上标准化了。软件一决胜负的关键在数据的处理。事实上，在真正做事这一点上，整个application framework 是无能为力的，也就是说对于数据结构的安排，数据的处理，数据的显示，Application Framework 所能提供的，无一不是单单一个空壳而已——在 C++ 语言来讲就是个虚函数。软件开发人员必须想办法改造（override）这些虚函数，才能符合个人所需。基于 C++ 语言的特性，我们很容易继承既有之类并加上自己的特色，这就是面向对象程序设计的主要精神。也因此，C++ 语言中有关于「继承」性质的份量，在MFC程序设计里头占有很重的比例，在学习使用MFC的同时，你应该对C++的继承性质和虚函数有相当的认识。

MFC 是一个零组件超级市场，所贩卖的零组件功能以及零组件

彼此之间的关系都已定义好；我们选择自己喜欢的零件，做出一个应用程序

Application Framework 究竟能提供我们多么实用的类呢？或者我们这么问：哪些工作已经被处理掉了，哪些工作必须由程序员扛下来？比方说一个标准的 MFC 程序应该有一个可以读写文件数据的功能，然而应用程序本身有它独特的数据结构，从 MFC 得来的零件可能与我的个人需求搭配吗？

假设你买了一个整厂整线计划，包括仓贮、物料、MIS、生管，各个部门之间的搭配也都建立起来了，包含在整厂整线计划内。这个厂原先是为了生产葡萄酒，现在改变主意要生产白兰地，难道整个厂都不能用了吗？不！只要把进货原料改一改、发酵程序改一改、瓶装程序改一改、整个厂的其它设备以及设备与设备之间的联机配合都可以再利用。物料之后到生管，装瓶之后到仓贮，仓贮之后到出货，再加上 MIS监控全厂，这些程序都是不必改变的。

一个整厂整线计划，每一单元之间的联机沟通，合作关系，都已经建立起来，是一种构造好的运作模式。抽换某个单元的性质或部分性质，并不影响整体作业。整厂整线最重要最有价值的是各单元之间的流程与控制。

反映到面向对象程序设计里头，Application Framework 就是整厂整线规划，Application Framework 提供的类就是上述工厂中一个一个的单元。最具价值的就是各类之间的交互运作模式。

虽然文件读写（此动作在MFC 称为Serialize）单元必须改写以符合个人所需，但是单元与单元之间的关系依然存在而且极富价值。当用户在程序中选按【File/Open】或【File/Save】，框架窗口自动通知Document 对象（内存数据），引发Serialization 动作；而你为了个人的需求，改写了这个 Serialize 虚函数。你对 MFC 的改写范围与程度，视你的程序有多么特异而定。

可是如果酿酒厂想改装为炼钢厂？那可就无能为力了。这种情况不会出现在软件开发上，因为软件的必备功能使它们具有相当的相似性，Windows 又强调界面一致性，不然会给用户的操作带来学习阻力。好比说程序想支持 MDI 接口，想支持 OLE，这基本上是超越程序之专业应用领域之外的一种大格局，一种大架构，最适合 Application Framework 发挥。

很明显，Application Framework是一组超级的类库。能够被称为 Framework 者必须其中的类性质紧密咬合，互相呼应。因此你也就可以想象，Framework 所提供的类是一伙的，不是单片包装的。你把这伙东西放入程序里，你也就得乖乖遵循一种特定的（Application Framework 所规定的）程序风格来进进程序设计工作。

三、各类学习资料上的说法

那其他资料上又是怎么描述Application Framework的？

1985 年，Apple公司的MacApp严格而系统化地定义出做为一个商业化 Application Framework 所需要的关键理念：

这里所指的 support 并不只是视觉性 UI 组件如menu、dialog、listbox...，还包括一个应用程序所需要的其它功能设备，像是 Document, View, Printing, Debugging。

另一个相关定义出现在 Ray Valdes 于1992年10月发表于Dr. Dobb's Journal 的 "Sizing up Application Frameworks and Class Libraries" 一文之中：

Donald G. Firesmith 在一篇名为 "Frameworks : The Golden path of the object Nirvana" 的文章中对 Application Framework 有如下定义：

* Nirvana 是涅盘、最高境界的意思。

Bjarne Stroustrup（C++ 原创者）在他的 The C++ Programming Language 一书中对于Application Framework 也有如下叙述：

Kaare Christian 在1994/02/08的PC Magazine 中有一篇"C++ Application Frameworks" 文章，其中有下列叙述（节录）：

两年前我在纽约北边的乡村盖了一栋 post-and-beam 房子。在我到达之前我的木匠已经把每一根梁的外形设计好并制作好，把一根根的粗糙木材变成一块块锯得漂漂亮亮的零件，一切准备就线程只待安装。（注：所谓post-and-beam 应是指那种梁柱都已规格化，可以邮购回来自己动手盖的DIY房子）。

使用Application Framework建造一个Windows 应用程序也有类似的过程。你使用一组早已做好的零件，它使你行进快速。由于这些零件坚强耐用而且稳固，后面的工作就简单多了。但最重要的是，不论你使用规格化的梁柱框架来盖一栋房子，或是使用Application Framework 来建立一个 Windows 程序，工作类型已然改变，出现了一种完全崭新的做事方法。在我的 post-and-beam 房子中，工作类型的改变并不总是带来帮助；贸易商在预制梁柱的技巧上可能会遭遇适应上的困扰。同样的事情最初也发生在Windows 身上，因为你原已具备的某些以 C 语言写 Windows 程序的能力，现在在以C++ 和Application Framework 开发程序的过程中无用武之地。时间过去之后，Windows 程序设计的类型移转终于带来了伟大的利益与方便。Application Framework本身把message loops 和其它Windows的苦役都做掉了，它促进一个比较秩序井然的程序结构。

Application Framework——建立Windows应用软件所用的C++类库。Windows API 是程序性的，Application Framework 则让你写面向对象式的Windows程序。它们提供预先写好的机能（以 C++ 类型式呈现出来），可以加速应用软件的开发。

Application Framework 提供数种优点。或许最重要的，是它们在面向对象程序设计模式下对Windows 程序设计过程的影响。你可以使用 Framework 来减轻例行但繁复的琐事，目前的 Application Framework 可以在图形、对话框、打印、求助、OCX 控制组件、剪贴板、OLE 等各方面帮助我们，它也可以产生漂亮的UI接口如工具栏和状态栏。

借着Application Framework的帮助写出来的代码往往比较容易组织化，因为 Framework改变了Windows管理消息的方法。也许有一天Framework还可以帮你维护单一一套代码以应付不同的执行平台。使用Application Framework的主要缺点是，没有单一一套产品广被所有的C++编译器支持。所以当你选定一套 Framework，在某个范围来说，你也等于是选择了一个编译器。

作者简介：荔园微风，1981年生，高级工程师，浙大工学硕士，软件工程项目主管，做过程序员、软件设计师、系统架构师，早期的Windows程序员，Visual Studio忠实用户，C/C++使用者，是一位在计算机界学习、拼搏、奋斗了25年的老将，经历了UNIX时代、桌面WIN32时代、Web应用时代、云计算时代、手机安卓时代、大数据时代、ICT时代、AI深度学习时代、智能机器时代，我不知道未来还会有什么时代，只记得这一路走来，充满着艰辛与收获，愿同大家一起走下去，充满希望的走下去。