![]() |
相關閱讀 |
![]() |
>>> 名人論史——近當代作家的史學觀點 >>> | 簡體 傳統 |
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
稱謂:
内容: