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

做软件的泡泡

最近突然萌发出这种想法，特地写了一篇贴在这里，如果已经有哪位大牛有过了这样的想法，请回帖，共同探讨；如果哪位大牛一眼就看出了这种想法中的天真之处，也请回帖，不吝赐教。

很多企业——尤其是以产品著称的企业——在同一个产品分类下一般都会设有两条产品线，分别表示主流产品和前卫产品，当然也可以表示高端产品和中端产品、个人产品和企业产品等等。当然这也不排除很多成功的企业在某个产品分类下只有一个产品线的例子，但那多数是由于行业的特殊情况所至，不再本文的讨论范围之内。

我不用眼睛也可以举出很多证明上面说法的例子来，下面的列表展示了很多这样的例子：
Microsoft / Windows 9x / Windows NT (过去)
Microsoft / Windows xp home / Windows xp pro （现在）
Macromedia / Flash MX / Flash MX pro
Symantec / Norton AntiVirus / Symantec AntiVirus
Real Networks / RealOne Player / RealPlayer
RedHat / Fedora Core / RedHat Linus Enterprise
Borland / JBuilder / JBuilder pro
Mozilla / Firefox+Thunderbird+Sunbird / Mozilla Suite
Sun Microsystems / Netbeans / Sun Studio
IBM / Eclipse / Websphere Studio Application Developer
Tencent / QQ / IM
用友软件 / U8 / NC
。。。 / 。。。 / 。。。

不做无用的列举工作了，这些足已经说明问题。这样的分类方式有很多益处，比如说客户分类明确啊、产品定价清晰啊什么什么的多了去了，但也不在这篇文章的讨论之内，这篇文章有更重要的问题要谈谈。

我们都知道上面的列表中有几款产品线是臭名昭著的，把它们挑出来，其实也就是Windows和Sun Studio。但是我相信还有很多很多这样的企业在维持着臭名昭著的两条产品线。我不是刻意贬低他们，其实我对Sun公司一直是怀有敬意的。他们之所以会这样，包括微软，是有苦衷的。这些苦衷来自这几个方面：

1。老客户。
    老客户是大公司最大的利润来源，也是他们技术上最大的绊脚石。多数老客户会认为a.保护他们以往对软件的投资是软件公司的一大任务，对于这个任务，软件公司应无条件接受。b.软件公司必须实现以前所做过的任何对他们有利的承诺。c.软件公司不应该在客户的项目中使用新技术，在该技术没有在其它项目中用过并取得全球性好评的情况下。

2。以往确立的技术标准。
    软件企业常会发布一些由本公司制定的技术标准。企图以此作为竞争壁垒，将竞争者阻止在城池之外。在大公司眼里，这些技术标准非常重要，它决定了大公司能不能留住合作伙伴的芳心，所以他们都会使出浑身解术支持这些技术标准。事实上我们想一想就知道在软件界，由非经济型软件组织制定的标准屈指可数。其结果就是，这些技术标准一旦变得落后了，软件企业再想改变它，即使是大公司，都会难上加难。

3。股东。
    软件公司的股东不见得是软件专家，他们是市场专家，他们不在乎你的技术会不会被程序员骂，他们只在乎技术会不会被客户骂。还有更可怕的，那就是人都护短，如果董事会决定研发一项没有前途的技术，他们永远都不会承认这个决定是错误的。

4。竞争对手，或是超大规模的合作伙伴。
    在某些问题上这两者扮演同样的角色。他们的决策会直接影响到软件企业对技术走向的开发。毕竟，多一个朋友少一个对手对谁都没有坏处。

5。新的大客户，包括老客户的新要求。
    某些大客户要求公司提供一些新的功能，这些功能可能会和上面三条中的某一条或几条相矛盾，这时软件企业既不想放弃作为利润源泉的老客户，也不愿意放弃争取新的客户，于是他们往往会自作聪明的选择一种折衷的方法，或干脆提供两个不同的产品特性，两种不同的服务，并将这两组客户划分为两个不同的市场细分。有时这会使人们得到哭笑不得的结果，但只要客户没有充足的理由放弃该软件企业，该企业就有机会将黑锅交给另一类客户群体去承担。于是他们会对老客户说，这是新客户的要求，而又对新客户说，这是老客户的最爱。

当面对这些问题时，软件企业虽不能说到了生死两难的境地，但起码也不能使本企业的技术天才们放手去干。笔者在这里提供了一套拍脑袋想起的方法，是否行的通，就要等待软件企业的决策者们去实践了。

以微软公司为例，Windows存在的绝大部分问题在于微软必须保证老客户开发的基于老版本windows的应用程序，因此每个版本的windows在发行时，虽然微软也想将代码重写一些，使用一些操作系统界的新特性，但又因为要顾及以往确立的技术标准进退维谷。我的建议是，微软公司应该为自己准备一块开放的试验田。比如推出一个全新的操作系统，也可以不以windows命名，（由于不能再叫“体验版”），我暂时称之为doors。doors是由全新的内核组成，不完全兼容之前版本的windows，也不必向前兼容（也就是doors的下一个版本不必兼容上一个版本），免费下载，部分组件开源，开源的部分可以遵循某个“规范性开源”许可证，（类似Sun的SPL），底层安全技术不开源。倘若真能如此，这块试验田基本上可以解决上面说的大部分问题，不信你听。

1。老客户。
    老客户可能根本不会用这个操作系统。而会继续使用windows，微软也会继续发行windows，毫不含糊。而某些思想开放的老客户可能部分的使用 doors，但由于开源许可证的存在，当他们在使用doors时微软不必承担除安全责任外的任何责任。

2。以往确立的技术标准。
    继续执行。windows永不变心。但是doors上的部分技术如果试验成功，取得技术界的一致好评，则微软可以放心大胆的用在下一个版本的 windows上。此时微软不但没有减弱对老技术标准的支持，反而将新技术标准的发布时间整整提前一个（或半个）产品周期。技术标准有了更好的独立性表示，也就更能受到人们的亲睐。

3。股东。
    由于doors可能依靠于contributor，公司在doors上的投资可能都不如一个Outlook大，大概和MSN Messenger差不多。

4。竞争对手，或是超大规模的合作伙伴。
    在操作系统领域微软最大的竞争对手就是Linux阵营，没关系，由于doors是开源的，它大可以模仿Linux的某些做法，抄袭特性和吸引大批技术专家的倒戈行为甚至有可能对对手造成致命打击。

5。新的大客户，包括老客户的新要求。
    与前几条矛盾的新要求会首先在doors上实现，而不是windows，这样选择权就自然落到了客户手上。新客户可以选择放弃自己的想法，使用 doors，或者——更明智的，先使用doors，如果这不是客户想要的特性就放弃或要求微软改进，如果是的，别担心，你可以选择下个版本的 windows，它将是个既具有这个特性又对你正在使用的windows兼容。这好比我去电影院看电影，可是上一场还没有散场，于是我就找个位子坐下来，要点瓜子和饮料，一边等待电影散场，一边可以把这里当成KFC，尽管KFC从没有卖过瓜子！无论新客户作出怎样的选择，他都没有掏出微软的手掌心。

例子讲完了，现在进入总结呈词阶段。在一个产品分类下面拥有两条产品线的软件企业可以选择开发第三条产品线，既非主流产品，也不是高端应用，而是新特性的试验品，试验品可以起一个非主流的名字，试验区为开源社区，试验对象既有部分技术天才，又充满了新老客户。试验品无需对任何产品100％兼容，包括其它两条产品线和以往发布的第三种产品，只要能起到预期的试验效果就行了。

这就是我的想法，见笑了。

做软件的泡泡



在HR的招聘环节中，招聘方式的选择往往存在一个成本性指标的问题。简单的说，就是如果两个同等效力的方案之中的某一个更便宜，企业就会选择，无论是企业的规模与行业的差别。

具体的说，应该遵循下面这个过程。

1。如果存在一种方法，正确的衡量某个人的能力与企业对这个人的愿景，那么企业就会选择。

2。遗憾的是脑经正常的人都知道这种方法是不存在的，那么企业必然会选择层层考核加试用来衡量一个人的能力。这对大企业来说是很应该的， 因为他们有的是钱，而需要合格的人来花这些钱。素质高的员工是利润的来源，客户信赖的对象，企业的门面，也是减少内部沟通成本的最佳选择。比如 P&G在很多大学都只招一个人，Intel和麦肯锡都只要硕士以上学历的人。

3。现在我们有了一种衡量能力的合理方法，可是对于中型企业来说，这种方法成本太高了，大多数中型企业面临人才的极度需求状态，但是他 们确实没有什么地方能够留住人才的，因此中型企业往往是薪水最高的，一般都会比大型企业要高。这时中型企业无法忍受应聘者的慢热情况，他们需要立即能上手 的人才，所以这些企业往往不看重应聘者的学历，而重视能力，园长就是这样进入国内最大的独立软件供应商的。

4。小企业又是完全另外的一回事，因为小企业愿意花更少的成本来衡量一个人的能力，他们既不愿花钱来判断谁最有能力（这个需要有伯乐， 而请伯乐需要花钱），也不愿意花钱给人做大量的培训，更不愿意让人随随便便实习。这些企业能找到的最省钱的判别人能力的方法就是请学历和社会经验代劳。这 也就是说到这样的企业找工作，做一份好简历是个非常重要的秘诀。

向管理发展的泡泡