插件式设计的架构模型与实例
----Do not call us, we will call you
转载时请注明出处:http://blog.csdn.net/absurd
插件式设计近年来非常流行,其中eclipse起了推波助澜的作用,提到插件式就会不由自主的想到eclipse。其实插件式设计并不是什么新事物,早在几十年前就有了。像X Server就是基于插件式设计的,除了核心功能外,它所有的扩展功能和设备驱动都是以插件方式加入进来的。
基于插件的设计好处很多:把扩展功能从框架中剥离出来,降低了框架的复杂度,让框架更容易实现。扩展功能与框架以一种很松的方式耦合,两者在保持接口不变的情况下,可以独立变化和发布。公开插件接口,让第三方有机会扩展应用程序的功能,有财大家一起发。另外,还可以让开源与闭源共存于一套软件,你的插件是开源还是闭源,完全由你自己决定。
基于插件设计并不神秘,相反它比起一团泥的设计更简单,更容易理解。各种基于插件设计的架构都有自己的特色,但从总体架构上看,其模型都大同小异。这里我们介绍一个简单的模型,并给出几个实例,希望对新手有所启发。
1. 基本架构
<shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></path><lock v:ext="edit" aspectratio="t"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 397.5pt; HEIGHT: 298.5pt" type="#_x0000_t75" o:ole=""><imagedata src="file:///C:/DOCUME~1/q/LOCALS~1/Temp/msoclip1/01/clip_image001.png" o:title=""></imagedata></shape>
插件式设计的应用程序,基本上可以用上图来表示。当然,此图是一种较高层次的表示,实际的设计会更复杂一些。我们在这里为了阐述方便,不用故意搞得那么复杂。
应用程序由应用程序框架、插件接口、插件和公共函数库四部分组成。
应用程序框架负责应用程序的整体运作,它清楚程序整个流程,但并不知道每个过程具体要做什么。它在适当的时候调用一些插件,来完成真正的功能。
插件接口是一个协议,可能用IDL描述,可能是头文件,也可能一段文字说明。插件按照这个协议实现出来,就可以加入到应用程序中来。当然,对于复杂的系统,插件接口可能有多个,各自具有独立的功能。
插件是完成实际功能的实体,实现了要求的插件接口。尽管实现什么以及怎么实现,完全是插件自己的自由。在实际情况来,一般还是有些限制,因为插件接口本身可能就是一个限制。如,实现编译功能的插件,自然不能实现成一个聊天功能的插件。
公共函数库是一组函数或者类,应用程序框架和插件都可以调用。它通常是一个独立的动态库(DLL)。应用程序框架本身是公用的,是代码复用的一种方式。但并不是所有可复用代码都可以放在框架中,特别是插件会用到的公共代码,那会造成插件对框架的依赖。把这些公共代码提取到一个独立的库中,是一种好的方法。
另外,值得补充说明一下的是插件接口。插件接口通常有两种:
通用插件接口:这一类插件接口是通用的,你无法从接口函数看出这个插件的功能。它的接口函数通常有这些函数:
init : 用于初始化插件,通常在插件被加载时调用。
deinit:用于反初始化插件,通常在插件被卸载时调用。
run:让插件起动。
stop:让插件停止。
至于插件要完成什么功能,要插到哪里,在init函数里决定,它调用公共函数库里的函数把自己注册到框架中某个位置。
专用插件接口:这一类插件接口是专用的,看到它的接口函数说明,你就可以大致了解它的功能了。
加入插件的方式通常采用配置信息来实现,配置信息可以是注册表,也可以配置文件。也可以动态注册进来,或者把插件放到指定的位置。
下面我们来看几个实例:
2. 桌面设计
最近一段时间完成了桌面模块的设计和实现。按照以往的经验,桌面模块通常是变化最多的一个模块,SPEC总是在不断的调整的效果,不同客户要求实现具有个性化的桌面,直到产品快发布了,桌面的SPEC还在不停的修改。另外,在智能手机中,桌面占有特殊的地位,很多东西都可能往桌面里塞,桌面不但是各种功能的大杂烩,还是一些系统消息的中转站。
这个任务比较棘手,所以在设计时就分外小心。首先想到的就是采用插件式设计,把外围功能独立出来,尽量简化框架的实现。
插件:每一个最小功能单元都是一个插件,它可以是可见的,也可以是不可的,也可以是动态变化的。比如时间、电池电量、网络连接、信号强弱、新事件(如SMS、MMS、EMAL、ALARM和未接电话等)、应用程序快捷方式、左右操作按钮和其它处理系统事件的功能单元。每个插件都用一个.desktop来描述,这是遵循freedesktop.org的标准的。
桌面框架包括:状态栏、开始菜单、操作栏、桌面区、事件管理器和主题管理器。而状态栏、开始菜单、操作栏、桌面区和事件管理器都是容器,容纳各种插件。对于可见的插件,可以有自己的表现方式,也可以采用通用的表现方式。
公共函数库:一些抽象的类、实现插件的辅助类以及其它一些可能被公用的类。
插件接口:对于不可见的插件要求实现事件处理功能,可见的插件还要求实现绘制功能。
3. 模拟器设计
一个同事负责设计另外一个平台的PC模拟环境设计。在我的建议下,他对架构作了调整。调整后的架构非常简单,也可以认为是插件式的设计,它由下面几部分组成:
应用程序框架:负责模拟器基本功能,如模拟键盘和显示设备、换肤功能等。
插件:就是被模拟的平台,如microwindow及相应的手机应用程序。尽管运行时通常只有一个插件运行,这样做仍然有意义,如果要换成minigui或者其它平台时,模拟器不需要作任何修改。
公共函数库:它由应用程序框架初始化一些信息和回调函数,然后供插件(即microwindow)调用,插件利用它来实现显示和输入等驱动程序。
插件接口:如起动和停止模拟平台等。
4. GIMP
GIMP是一个功能强大的图形图像编辑器,典型的基于插件式的设计,在《unix编程艺术》中,作为插件式设计示例介绍过。
应用程序框架:GUI
插件:完成图像的各种转换和处理功能,如模糊、去斑和色彩调整等。
公共函数库:放在libgimp.so里。
插件接口:对GIMP感兴趣的朋友,可以到官方网站上去阅读更多的文档。