简介：
本文提出了一种界面设计中的架构模式－界面组装器模式，它致力于分解界面 ，将界面和组装行为解耦，将界面逻辑处理与领域逻辑处理解耦，这样我们在开 发 GUI 胖客户端界面应用时可以从众多的界面控制管理中解脱出来，而专注于我 们的后台业务逻辑的开发。通过该模式，我们可以动态地组装我们的界面，我们 甚至还可以在我们的界面中轻松地插入 transaction 事务或 session 会话管理 。
本文将通过分析设计一个架构的过程来讲解该模式，从一个简单的设计模型开 始，一步步走向一个完整的架构。借此也向大家展示一个架构设计的思维历程。 另外，本文给出了 Eclipse SWT(Standard Widget Toolkit) 的示例。
问题引出
界面设计常常是模式产生的根源，无论是架构模式，还是设计模式，比如 MVC 模式，Observer，Facade 等，也是整个软件行业向前发展的动力。遗憾的是，即 使在软件技术发达的今天，界面设计仍是软件设计中的难以突破的瓶颈之一。我 们用过 Java swing 或 Eclipse SWT 作过项目的都知道，要将界面进行分解是很 困难的，它不像我们的业务逻辑，可以方便地按职责分解到不同的类中去实现， 因为各个业务逻辑之间耦合度很低。但界面逻辑不一样，你不可能将一个文本框 的读取操作委任到另一个类中去，而且各个界面元素之间相互依赖，无法去除耦 合，一般的做法只能是在界面元素的事件触发(比如按钮点击事件)时，将输入数 据封装成一个数据对象传给后台的逻辑处理类来处理。
Eclipse 的 Wizard 框架在界面分解上提供了一种很好的实践，它可以将按钮 区和其他界面区分离出来，用类似 MVC 的方式实现了 Wizard 框架。但这个实现 并非没有瑕疵，一个缺点是 wizard 是一个 plug-in，这样的话就减少了可重用 性，不能移植到 eclipse 以外的环境。另一个缺点就是它引入了很大的复杂性， 而且在一些对界面元素的控制上丧失了一些精细控制的能力，这可能是它过度地 强调了自动化和用户扩展的方便性的缘故。比如，用户不能将自己的逻辑插入按 钮区的按钮事件控制中，而只能在自定义区的界面元素 Listener 中设定按钮区 状态，如果用户自定义的界面元素很多，就需要很多个 Listener 来组合判断一 个按钮状态（如是否进行“下一步”），这样的话就很影响性能，而且无端地多 了一堆复杂的逻辑判断，也就是说本来只需在按钮 Listener 事件中处理的逻辑 现在要分散在各个界面元素的 Listener 中去处理。这也正是设计上一个值得反 复强调的普遍问题：当你要保持架构或设计的完美性时必然会以丧失其他特性为 代价。世上永远没有完美的东西，我们只关注适合我们的。
我下面要提出的这个架构模式的灵感来自于我的一个真实项目，一个用 RSA（ Rational Software Architect）/Eclipse 建模的项目，在 RSA 环境中，读写模 型都必须在一个特有的 context 下才能操作，这就意味着我在界面的启动之前必 须封装好输入数据，关闭之后返回输出数据，而不是直接处理数据，必须对输入/ 输出数据对象进行封装。正如前面提到的，这种情况界面设计中很普遍。所以， 在模式命名时我用了组装器-assembler 这个词，有一层意思是输入/输出数据对 象的组装，另一层意思就是界面部件（界面元素的集合）的组装，这里的组装还 有更深层次的涵义就是指界面部件的可装配性，可以在运行时动态组装。而且这 个模式可以用任何语言（Java，C++ 等）来实现。在这里我会从一个简单的设计 模型开始，一步步走向一个完整的架构。借此也向大家展示一个架构设计的思维 历程。本文中给出了 Eclipse SWT(Standard Widget Toolkit) 的示例。