2,096
社区成员
我是荔园微风,作为一名在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?别认为这是领导者的事情不是工程师的事情,有这种想法你就永远当不成领导者。
一般而言,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可不是那么容易学的,花多少时间才能登堂入室可还得凭各人资质和基础呢。
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程序外貌。隐藏在精致画面背后更重要的是,就如我在前面说过,对象与对象之间的关系已经存在,消息的流动程序也都已设定。当你要为这个程序设计真正的应用功能,不必在意诸如我如何得知用户按左键?左键按下后我如何启动某一个函数?参数如何传递过去等琐事,只要专注在左键之后真正要做的功能动作就好。
文章来源: https://blog.csdn.net/wang2015cn/article/details/131133514
版权声明: 本文为博主原创文章,遵循CC 4.0 BY-SA 知识共享协议,转载请附上原文出处链接和本声明。