WORD文档分类管理插件.doc
- 文档编号:1890201
- 上传时间:2022-10-25
- 格式:DOC
- 页数:7
- 大小:14.74KB
WORD文档分类管理插件.doc
《WORD文档分类管理插件.doc》由会员分享,可在线阅读,更多相关《WORD文档分类管理插件.doc(7页珍藏版)》请在冰豆网上搜索。
摘要
随着计算机普及和计算机科学技术的发展,并且由于电子文档具备方便性、快捷性和易操作性,人们将大部分信息以电子文档形式储存和归档。
面对与日骤增的海量数据信息,对它们进行有效的整理和管理变得尤其重要。
人们越来越期望能在统一的文档操作界面上,对各类文档信息进行收集收藏、整理归档,方便查询。
本文详细介绍了Word文档分类管理软件的设计和实现。
软件对用户需求做了充分的考虑,进行正确和较完整的设计,使得能在统一的文档界面上,方便地对磁盘上所有文档(可包括其它存储介质,如:
移动硬盘等,文档指MicrosoftOffice里的Word文档,后缀名为.doc)进行分类管理。
文档管理功能包括:
新建记录、打开文档、编辑记录、删除记录或文档、添加文档等。
关键词:
COM组件;Word插件;文档分类器
TheDesignandImplementationofaWordAddinforDocumentClassificationManagement
Abstract
1引言
1.1课题背景
随着计算机普及和计算机科学技术的发展,电子文档具备有方便性、快捷性、易操作性,人们将大部分信息以电子文档形式储存和归档。
面对与日俱增的海量数据信息,对它们进行有效整理和管理变得尤其重要。
人们越来越期望能在统一的文档操作界面上,对各类文档信息进行收集收藏、整理归档,方便查询。
1.2本课题研究的意义
Word文档是实际工作学习中最为常用的文档格式之一,为了增强Word、Excel等软件的自动化能力,人们开发了各种提高办公效率的软件,它们大多数实用、专业性强。
为了避免用户做大量重复性的工作,提高Office办公效率,达到提高其实用功能的目的,可根据具体工作内容要求,编写出最具本地化、个性化、最合适的软件。
1.3本课题的研究方法
通过对人们日常Office办公情况及存在问题进行透彻分析,并根据办公习惯,总结出较可行的解决方案。
2组件、COM、接口、插件
2.1组件
一个应用程序通常是由单个的二进制文件组成。
当编译器生成此应用程序之后,在对下一版本重新编译并且发行新生成的版本之前,应用程序一般不会发生任何变化。
操作系统、硬件及客户需求的改变都必须等到整个应用程序被重新编译之后才能够得以认可,整个软件工程就这样随着已发行软件而日益老化。
目前这种状况已经发生了变化。
人们认识到应用程序在发行之后不应保持那种静止的状态。
开发人员应找出一种方法,以能够给已经发行的软件不断地注入新的活力。
这种解决方案就是将整个的应用程序分隔成多个独立的部分,也即组件。
此作法的好处是可以随着技术的不断发展而用新的组件取代已有的组件。
此时的应用程序将不再像以前那样是一个在发行之前就已命中注定要过时的静态实体,而是可以随着新组件不断取代旧的组件而趋于完善,并且从已有的组件可以建立全新的应用程序。
传统的作法是将应用程序分割成文件、模块或类,然后将它们编译并链接成一个铁板一块状的应用程序。
它与组件建立应用程序的过程(称为是组件架构)有很大的不同。
一个组件同一个微型应用程序类似,即都是已经编译、链接好并可以使用了,应用程序就是由多个这样的组件打包而得到的。
各定制的组件可以在运行时同其他组件连接起来以构成某个应用程序。
在需要对应用程序进行改进时,只需将构成此应用程序的组件中的某个用新的版本替换掉即可。
当然将铁板应用程序拆分成组件需要一个强大的工具。
我们所用的工具就是COM。
COM,即组件对象模型,是关于如何建立组件以及如何通过组件建构应用程序的一个规范。
目前Microsoft的几乎所有应用程序都使用了COM。
2.1.1使用组件的优点
前面已经提到过组件架构的一个优点:
应用程序可随时间的流逝而发展进化。
除此之外,使用组件还有一些可以使对已有应用程序的升级更加方便和灵活的优点,如应用程序的定制,组件库以及分布式组件等。
1.组件架构从本质上讲就是可被定制的,因此用户可以用更能满足他们需要的组件来将某个组件替换掉。
2.组件架构最引人注目的优点之一是快速应用程序开发。
这一优点可以使开发人员从某个组件库中取出所需的组件,并将其快速地组装到一块以构造所需的应用程序,如同搭积木块一样。
这种从标准的部件构造应用程序的做法,很长时间以来一直是软件工程师们的一个未曾实现的梦想。
但是现在这一梦想随着ActiveX控件(以前被称作是OLE控件)的开发而正在被变为现实。
VisualBasic、C、C++以及Java程序员都可以利用ActiveX控件加速应用程序及Web页面的开发。
2.1.2对组件的需求
使用组件的种种优点直接来源于可以动态地将它们插入或卸出应用程序。
当然为了实现这种功能,所有的组件必须满足两个条件。
第一,组件必须动态连接。
第二,它们必须隐藏(或封装)其内部实现细节。
两个需求是相互依赖的。
动态链接对于组件而言是一个至关重要的需求,而信息隐藏则是动态链接的一个必要条件。
1.动态链接:
我们的最终目标是使用户在应用程序的运行过程中能够将组件替换掉。
虽然并不是在所有的应用程序中都需要给用户提供这种控件,但我们却希望能够将组件动态地链接到一起。
可以设想一下对于一个由组件构成的,但不能在运行时进行链接的应用程序,当用户需要改变其中的某个组件时会发生什么。
此时开发人员不得不将整个程序重新链接或编译一遍,然后重新发行新的版本。
但是这种重新编译或链接对于最终用户几乎是不可能的事情。
即使他们知道如何链接,但他们可能没有链接程序,或者没有合适的链接程序。
这种需要每次改变一个组件时就将其链接一遍的程序和传统的铁板一块的程序实际上没有什么差别。
2.信息封装:
为组成一个应用程序,需要将各组件连接起来。
当需要将某个组件用新的组件替换掉时,需要将此组件同系统断开,然后将新的组件连上去。
显然新的组件必须按同样的方式连接到系统中,否则将需要重新编写、重新编译或重新链接这些组件。
不论组件或应用程序是否支持动态链接,如果改变了某个组件同其他组件的连接方式,那么整个系统的整体性实际已被破坏了,此时至少需要将整个系统编译一遍,甚至可能需要重新编码。
对于一个应用程序或组件,如果它使用了其它组件,那么我们称之为一个客户,客户通过接口同其他组件进行连接。
如果某个组件发生了变化但其接口没有任何变化,那么它的客户将不需要进行任何修改。
类似地,若客户发生了变化但没有改变其接口,那么它连接的组件也不需要任何改变。
但是如果客户或组件的修改导致了对接口的修改,那么接口的另一方也应发生相应的变化。
因此为充分发挥动态链接的功能,组件及客户都应尽可能不要改变它们的接口。
这意味着它们必须被封装起来。
也就是说,组件及客户的内部实现细节不能反映到接口中,接口同内容实现细节的隔离程序愈高,组件或客户发生变化时对接口的影响将越小。
在接口没有发生任何变化时,对组件的修改将几乎不会对应用程序的其它部分产生什么影响。
这种将客户同组件实现相应隔离开来的要求对于组件加上了一些限制:
1.组件必须将其实现所用的编程语言封装起来。
任一客户都应能使用任一组件,不论他们是用什么编程语言实现的。
将实现的编程语言暴露出来只会在组件及客户间引入新的依赖。
2.组件必须以二进制的形式发布。
如果想将实现组件的编程语言隐藏起来,那么在发布时它们必须是已被编译、链接好并且马上就可以投入使用的。
3.组件必须可以在不妨碍已有用户的情况下被升级。
一个组件的新版本必须既能够同老版本的客户一起使用。
也可以同新版本的客户一起使用。
将以上几点加以说明:
1.与语言的无关性。
为方便讨论起见,假定某个应用程序只能使用由ObjectiveC编写的组件进行定制。
这样一来,将不会有太多的人来为此应用程序编写组件,因为大多数编程人员使用的是C++。
以后我们可能会用C++来编写组件,从而使得应用程序可用的组件多起来。
但如果后来另外有一种语言,假设是EspressoBeans变得流行起来,大家都放弃C++,转而使用这一语言。
为了使用应用程序不被淘汰,我们需要用这种新语言来编写组件。
如此就有了三种截然不同的编写组件的方法。
在一个与语言无关的架构中,任何人均可以编写组件,并且这些组件不会因为编程语言的发展而过时。
2.用户可能会拥有使用同一个组件的两个客户应用程序。
假定其中的某个应用程序被指定使用某个组件的新版本而另一个应用程序被指定来使用其老版本。
显然人们希望老应用程序仍能够使用新安装的新版本组件。
但这种向后兼容的能力不应对组件的发展造成限制。
强行改变某个组件的功能以使之适应新应用程序的需要,同时使其能支持老的应用程序仍应是可能的。
3.2COM
软件工程发展到今天,从一开始的结构化编程,到面向对象编程,再到现在的COM编程,目标只有一个,就是希望软件能像积方块一样是累起来的,是组装起来的,而不是一点点编出来的。
结构化编程是函数块的形式,通过把一个软件划分成许多模块,每个模块完成各自不同的功能,尽量做到高内聚低藕合。
件工程的核心就是要模块化,最理想的情况就是100内聚0藕合。
结构化编程方式只是一个开始。
下一步就出现了面向对象编程,它相对于面向功能的结构化方式是一个巨大的进步。
面向功能的模块化方法它的着眼点是事物之间的联系,它眼中看不到事物的概念它只注重功能。
面向功能的结构化方法因为它注意的只是事物之间的联系,而联系是多变的,事物本身可能不会发生大的变化,而联系则是很有可能发生改变的,联系一变,那就是另一个世界了,那就是另一种功能了。
如果我们用面向对象的方法,我们就可以以不变应万变,只要事先把事物用类描述好,我们要改变的只是把这些类联系起来的方法,只是重新使用我们的类库,而面向过程的方法因为它构造的是一个不稳定的世界,所以一点小小的变化也可能导致整个系统都要改变。
DLL的缺点就是COM的优点。
COM和DLL一样都是基于二进制的代码重用,所以它不存在类库重用时的问题。
另一个关键点是,COM本身也是DLL,既使是ActiveX控件.ocx它实际上也是DLL,所以说DLL现在还是有重用上有很大的优势,通COM本身的机制改变了重用的方法,以一种新的方法来利用DLL,来克服DLL本身所固有的缺陷,从而实现更高一级的重用方法。
COM没有重名问题因为根本不是通过函数名来调用函数,而是通过虚函数表,自然也不会有函数名修饰的问题。
路径问题也不复存在,因为是通过查注册表来找组件的,放在什么地方都可以,即使在别的机器上也可以。
也不用考虑和EXE的依赖关系了,它们二者之间是松散地结合在一起,可以轻松地换上组件的一个新版本。
4.3接口
接口提供了两个不同对象间的一种连接。
实际上计算机程序是通过一组函数而连接起来的。
这组函数实际上就定义了程序中不同部分的接口。
DLL的接口就是它所输出的那些函数。
COM中的接口也涉及到一组由组件实现并提供给客户使用的函数。
对于COM来说,接口是一个包含一个函数指针数组的内存结构。
第一个数组包含的是一个由组件所实现的函数的地址。
对于COM而言,接口就是此内存结构,其它东西均是一个COM并不关心的实现细节。
接口的作用:
在COM中接口就是一切。
对于客户来说,一个组件就是一个接口集。
客户只能通过接口才能同COM组件打交道。
从整体上讲,客户对于一个组件可以说是知之甚少的。
在某些情况下,客户甚至不必知道一个组件所提供的所有接口。
可复用应用程序架构:
说组件仅仅只是接口的实现细节当然有点言过其实。
不管怎么说,一个未被实现的接口实际上什么也不能完成。
但是组件可从应用程序中删除并可用另外一个组合来取代之。
只要新的组件支持同组件相同的接口,那么整个应用程序将仍然能够工作。
单个的组件并不能对整个应用程序产生决定的作用。
相反,用以连接组件的接口将对整个应用程序产生决定性的作用。
只要接口保持不变,那么组件可以任意地更换。
接口同木板房中的大梁非常类似。
这些大梁决定了整个房屋的结构。
同样可以将应用程序所用的组件替换掉,这样应用程序的行为将会发生变化,但从结构上讲,整个应用程序并没有发生任何变化。
使用组件来构造应用
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- WORD 文档 分类 管理 插件
![提示](https://static.bdocx.com/images/bang_tan.gif)