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的其它模式会在今后的文章中再次讨论，即将出版，敬请留意。这里有很多想法还不太全面，请参与我的讨论并提出你的想法，或者增加你的模式。谢谢。

做软件的泡泡