>>>  名人論史——近當代作家的史學觀點  >>>

簡體     傳統

1994.12

别人手上都是针刺飞弹，
拿着 57 步枪的你如何抗衡 ?
真的要执白梃以挞坚甲利兵吗 ?

使用 Application Framework，
才跟得上最新介面与最新技术。
如果能因此轻易做出和世界级软体同等级的 UI 介面，
你心不心动 ? 

每个人都说以 SDK 开发 Windows 软体多麽烦人，多麽痛苦。我从不认为 ! 如果你了解每一个程序的每一个原由，何难之有 ? 可重复使用的 C++ 软体元件和设计良好的 C 函式之间有很大的差别吗 ? 在原有的 Windows 程式码中玩一点剪贴游戏，把视窗标题和视窗类别名称改一改、图式 (icon) 改一改、颜色改一改、表单改一改，然後在视窗函式的 switch 叙述中多打造几个 case，麻烦吗 ? 一点也不 ! 倒有一种完全掌握每一点每一滴并且「看你往哪儿跑」的快感。这种快感大概只有骨子里流着 100 ㄆㄚ 理工血液的工程师才享受得到，也才愿意享受。

噢噢，以上是我一年前的想法。自从我知道并了解 Application Framework 这种开发工具，我就不做如是想了。没有比较，难以分出高下，SDK API 原是高阶的应用程式介面，在 Application Framework 面前却宛如低阶的组合语言。

(注 : SDK 全名是 Software Development Kit，软体开发工具。每一个环境都可以 有它自己的 SDK。例如 DOS Extender 也可以有 SDK。但现在 SDK 三个字常常成为 Windows SDK 的代名词。其实把所谓的 Windows SDK 程式称为 Windows API 应用程式 恐怕恰当些，这种程式不限使用 Microsoft SDK，也可以使用 Borland、Symentec 或其他厂商的 Windows 软体开发工具进行编译联结)

■ Application Framework

什麽是 Application Framework ? 你可以说这种产品在良好的规划与测试之下，提供大量的一般性程式机能；这些机能彼此之间有强大的凝聚力。我们来分析一下这个很文诌诌、很不具体的定义。

1) 在良好的规划与测试之下 - 这是 Application Framework 设计者与开发人员的责任， 我们只是使用者，不干我们的事。当然，掏钱的时候，你得谨慎评估哪一套 才是良好规划与测试之下的产品，因为通常选择了一套 Application Framework， 也几乎就跟定了一套编译器。

2) 提供大量的一般性程式机能 - 什麽是一般性程式机能 ? [About] 对话盒、[File] 表单、 [Edit] 表单、[Help] 表单、工具栏 (toolbar)、状态栏 (status bar) 等等都是。 撇开使用者介面不谈，资料的储存与显示、印表机输出与输出前的预视也都是一般性程式 机能。尤有甚者，SDI (Single Document Interface，单文件介面)、MDI (Multiple Document Interface，多文件介面) 和 OLE (Object Linked & Embedded， 物件联结与内嵌) 也都算是一般性程式机能，因为它们并不涉及一个应用程式特定 之资料型态。

关於应用程式特定之资料型态，我必须对上面的说明有所补充。上面提到的资料 储存与显示、印表机输出以及输出预视，都与资料结构有关。Application Framework 绝对不可能知道它的使用者将如何规划资料格式，所以它提供的只是一个空壳， 和一些管理资料的辅助工具 (诸如阵列、串列)。你，身为一个 Application Framework 的用户，必须因应实际需要之资料结构，设计出关键性的处理函式， 例如档案存取动作 (在物件导向领域中称为 Serialization，也就是 MFC 的 Serialize 函式)、显示幕的输出动作 (在 MFC 中称为 OnDraw 函式)。这些位居 关键地位并且与应用程式之资料格式息息相关的函式，需要你自己设计。

如果关键性的动作都靠我们亲手完成的话，Application Framework 除了 对 UI 介面有些贡献，又带来什麽其他价值呢 ? 它的价值在於下面一个性质。

3) 机能彼此之间有强大的凝聚力 - 你不妨把 Application Framework 视为一种工具， 可以快速制造出一部汽车的华丽外壳 (目前全世界最流行的外壳)，以及汽车内部 的油路电路，只缺最重要的引擎部份。依车主的喜好，植入引擎後，这部汽车就能 上路上工了。在这里我要强调的是「油路电路」，当你使用 Application Framework 提供的各个程式机能 (软体元件)，它们之间有强大的凝聚力，关系密切。举个例子， 你在 [File Open] 对话盒中 (这是 Application Framework 提供的) 选择一个 档名，档名会自动包装，开启一个 Archive 档案，再把 handle 交给那个负责磁碟读写动作的函式 (在 MFC 名为 Serialize)。 所以你 (应用软体设计者) 不必再管琐屑的杂事，只要专心於最关键的磁碟读写动作 即可。不必在取经的大道上，常常迷失於路旁幽径。

资料的本体我们称为 Document，资料的外显我们称为 View。再举一个 Document-View 之间关系密切的例子 : 你可以为一份资料产生许多观察视窗 (许多 View)，这些子视窗 的管理已内含在 MDI 介面之中，我们什麽也不必做；如果你在某一个 View 视窗中修改 了资料内容，只要让 Document 发出命令，所有的 View 视窗都同步更新。

一般的类别库 (Class Library) 和 Application Framework 有什麽差别 ? 关键就在於上述的第三项特质。由於要用就得用一整组类别，所以你得乖乖遵循特定的程式风格(程式写法)。对於艺术家们，这是难以忍受的事；身为一个工程师的我，想到的却是一句老话 :「没有规榘，无以成就方圆」。只要能够提升我的生产力，又有长远的支援，我很乐意接受这种没有痛苦的束缚。

■ MFC 与 OWL

Application Framework 以什麽型态呈现出来 ? 它又该如何使用呢 ?

物件导向产品，当然是以骨子里已有物件导向精神的 C++ 语言来完成最适当。Application Framework 就是以 C++ 类别库 (Class Library) 的形态呈现出来。只要你充份了解 C++ 语言中的继承性质，以及虚拟函式的精义，就能够把 Application Framework 运用得很好。Application Framework 设计者把那些最关键性的、最与应用程式特殊格式息息相关的动作通通设计为虚拟函式，等着你改写 (override) 它。

PC 环境中出现两套成功的 Application Framework 产品，一是 Microsoft 公司的MFC (Microsoft Foundation Classes)，一是 Borland 公司的 OWL (Object Windows Library)。这两套产品都有上述的 Document-View 架构，类别的划分大致上也相似。二者技术各有所长，但 MFC 占着东家是 Windows 开创者之便，在 OLE 及 ODBC 等方面的类别支援上，动作比较迅速。另外，以加盟店 (注) 的数目来看，MFC 的声势也浩大些。(注: Microsoft、Symantec、Metaware、Watcom 都采用 MFC 做为其开发环境中的 application framework)。

除了 Application Framework 本身，它搭配的整合开发工具也是我之所以认为传统SDK 程式员太过辛苦的原因。MFC 搭配 Visual C++ 的各个 Wizards，OWL 则搭配Borland C/C++ 的各个 Experts。这些开发工具为我们自动产出骨干程式码，维护类别与虚拟函式，自动帮我们加上讯息处理常式的空壳、函式原型、讯息映射表格的项目...，总之，为我们做掉一切琐事，让程式员在关键的虚拟函式身上专心下功夫。

不管你喜欢哪一个产品，我都要说，你是睿智的。选择 Application Framework 就是一种睿智的表现，因为它是组合式软体机能最好的杠杆支点。

■ 渐悟 C++

喊了很久，C++ 却变成程式设计领域里的一个图腾 --- 一种被崇拜的符号和标帜，用来区分氏族血统。软体界，至少咱们国内的软体界，有着 OOP (注) 这麽个小小团体，身上流着贵族的血液。(注 : OOP 是 Object Oriented Programming 的缩写，发声类似"巫婆")。

「贵族」表示人数稀少，也表示 C++ 难以亲近 (根据我所接触的软体界朋友以及研讨会学员的反应)。稀少和难以亲近不是 Bjarne Stroustrup (C++ 原创者) 的目的。常听 OO 专家说，人类的思维本来就是物件导向的，并且举一大堆猫狗蜗牛猴子动物园做为例子，但是根据平庸如我的经验，我想人类命令电脑解决问题的时候，思路恐怕还是「一条鞭」、循序性的。既然知道电脑没有人类的智慧，既然知道电脑是一个指令一个指令地执行，我就很难一下子被说服，一段码和另一段码会「自动」产生什麽关联。物件导向式的软体 UI 介面的确是直觉而非常容易上手的，物件导向式的软体技术却需要教导、学习、揣摩。揣摩就表示要慢慢地磨细细地咽，所以平庸如我者，接触了 C++ 数年之後，才慢慢体会了一些「物件导向」的精神。

C++ 是一种扭转程式员思维模式的语言。一个人思维模式的扭转，不可能那麽轻而易举。传统循序性语言用得愈多愈久的人，快速接受 C++ 的机率愈低。没学过 C 而直接学 C++ 者，我只遇过一个 (C++ 中还不是有 C ?!)。至於说 C++ 是他这一生第一个程式语言的人，我还没有碰过。我讲这麽多是要告诉你 : 觉得 C++ 不容易体会的人，你绝对不会是第一个，而且你也绝不会孤单 (至少我与你作伴)。就在今天早上，一位资深 (8 年) 软体工程师还和我聊到 :『C++ 真的那麽好那麽重要嘛 ? 真的那麽自然吗 ? 怎麽我 ...』。

大 愈举愈高的时候，即使看不清楚上面写些什麽，大多数人也会跟着摇旗呐喊。我们应该有自己的见解。我并不讨厌 C++ 和 OO，甚而愈来愈喜欢它，但当你诉说 C++ 多好多好的时候，应该要从内心里说，从自己的体会与经验来说，不是拾别人的牙慧来说。C++ 很重要，至少，不会 C++ 你就不能使用 Application Framework --- 在我看来这够严重的了。Application Framework 可能会成为学习 C++ 的重大诱因，至少，这个诱因在我身上成立。

■ 效率与移植性

Application Framework 应用程式当然比单纯的 Windows API 程式效率低，因为它多了一些包装。有些动作包装了好几层，有些动作包装比较少。无论如何包装，都会扯效率的後腿。你该评估的，是这个「慢」有没有慢在节骨眼儿上。

对於效率，我个人比较不那麽在意。硬体的进步很快，让 CPU 振荡频率为我们解决效率的苦恼，对许多应用领域而言是足够的。我比较在乎程式的维护、开发效率、以及跨平台性。Application Framework 既然有包装，就可以在包装之下更换不同的 API。MFC 对 16 位元应用程式和 32 位元应用程式的移植性做的不错 (这是我实地使用 Visual C++ v1.5 和v2.0 之後的心得)，OWL 则在跨平台方面有比较远大的志向 (宣称要横跨 OS/2、Windows、Mac、UNIX)。

■ 良心建议

赶快学习 Application Framework 并且实际应用它，这是我的良心建议。如果别人的手上都是针刺飞弹，拿着 57 步枪的你如何抗衡 ? 真的要执白梃以挞坚甲利兵吗 ? 像 OLE 这种还在拼命往前冲的新规格与新技术，如果你要在程式中含入它，非得使用 Application Framework 不可。使用它，才跟得上最新介面，最新技术。一位朋友很烦恼手上十万行的程式，不知如何移植到 MFC。我想他算是好的，至少他已经企图打开机会的大门。

Andrew Schulman 曾在 Dr Dobb's Journal 上说 :『Microsoft 的应用软体愈来愈像作业系统的一部份』。你可以从很多角度去想这句话。这话嘲讽 Microsoft 藉着作业系统的优势哄抬其应用软体。从软体开发的角度，我联想到的是，Microsoft 把它的最佳软体 (Excel、Word) 上的各种最好最新的使用者介面，都包装在MFC 类别中给你使用。如果能因此轻易做出和这些世界级软体同等级的 UI 介面，你心不心动 ?
 

侯捷 2010-07-28 06:31:00