posts - 80,comments - 749,trackbacks - 2
UI框架的组织模式
The Orgnizing Patterns Of UI Framework


原著:Brian Sun

UI框架中有很多组件,很多类,很多细小而繁多的标准,这些特征使得UI框架成为一个业务逻辑和底层代码的复杂无序混合体,对它的类组织方式的研究也就显得特别有模式化编程的意义。

Pattern 1:Composite
    几乎所有时下流行的UI组件都会遵循Composite模式,比如AWT、Swing、Java2D、SWT、JFace、EclipseUI、 Draw2D、GEF以及.NET世界的Windows Forms。该模式的大概含义是,子组件和母组件是同一个类型的。比如一个Button应该是安排在一个Panel上的,但是Button和Panel可能都是一个Container或者都是一个Composite。

Pattern 2:绘制前组织
    目前公共领域的设计模式还没有可以精确的表达这个思路的名词,所以我就自做主张,起了个名字,后面的Pattern如果用中文命名,也是这个原因。该模式的大概含义是,子组件应赶在母组件绘制之前将自己显式的加入母组件。比如说,如果Button要继承Panel的某个属性(我是指Button要得到 Panel的某个知识),那么就要赶在绘制之前显式的将这个Button对象add到Panel中去。绘制前组织的典型例子是AWT、Swing、 Java2D、Draw2d等。

Pattern 3:构建时组织
    和某种工厂方式相似,构建时组织是在类的构造器上做文章。该模式的大概含义是,子组件在构建时就必须确定它属于哪个母组件,以便在后面的操作中与母组件户动。比如Button所有的构建器都要求传入一个Composite对象作为parent。这个模式与上面的Pattern 2完全不同,其典型例子有SWT、JFace、EclipseUI、GEF(都是一家的)。

Pattern 4:MVC
    几乎所有时下流行的UI组件都或多或少的使用了MVC,或不太严格的MVC,或MVC某个角度的思想。该模式用在UI系统上的大概含义是,将组件的绘制、设置和事件处理分开,在不同的角色中完成。我在本文所举的所有例子中,只有GEF实现了严格和完美的MVC,而AWT、Swing、Java2D等组件(都是由Sun开发或Sun和Netscape合作开发的)则使用了一个著名的同时也是最容易被搞混淆的MVC变种。该变种中也有三个角色,绘图器代理、无知的模型和监听器、原型组件和事件处理方法。而微软的MFC也采用了MVC的另一个著名变种,Document-View,这个变种显然只有两个角色。

Pattern 5:Delegate
    性能和可移植性是一直是UI平台最关注的两个问题。性能依靠尽量少的载入类,可移植性则依靠对更多图形库的支持,这两件事都需要将硬性的绘图方法或事件处理方式分离出去,交给代理完成。该模式的含义是,绘图工具本身不绘图,它只负责决定应该由它的哪个代理完成,并负责为代理绘制图形搜集参数。 Eclipse和Sun的主要工具都采用了这一模式,不同的是Eclipse也在事件处理环节应用了代理模式,因为事件被触发之前没有理由将它的实现读入内存,所以实现应该由代理完成。

Pattern 6:Layer
   Eclipse采用了严格而完美的分层模型,有严格界限的层次至少有三个,分别是org.eclipse.swt, org.eclipse.jface, org.eclipse.ui。其中SWT负责绘制简单的组件,提供简单组件的功能。JFace负责绘制复杂交互方式的组件,有些JFace的组件包装了 SWT的组件,并提供了随组件而走的服务。这两个包都可以在Eclipse以外的平台上使用。UI层则完成Eclipse平台的主要UI功能,很多地方提供了系统唯一的服务,并包装了JFace的组件。Draw2D建立在SWT之上,包装了SWT使其能更好的为绘制二维复杂图形而服务。GEF建立在 Draw2D和EclipseUI层的基础之上,为Eclipse Workbench提供某些功能。

本文只涉及了UI架构的组织模式,并未涉及其它模式,关于UI的其它模式会在今后的文章中再次讨论,即将出版,敬请留意。这里有很多想法还不太全面,请参与我的讨论并提出你的想法,或者增加你的模式。谢谢。

做软件的泡泡

posted on 2005-02-26 04:35 Brian Sun 阅读(2765) 评论(0)  编辑  收藏 所属分类: 软件

只有注册用户登录后才能发表评论。


网站导航: