界面组装器模式

界面组装器模式2011-10-01 IBM 刘岳林简介：

本文提出了一种界面设计中的架构模式－界面组装器模式，它致力于分解界面，将界面和组装行为解耦，将界面逻辑处理与领域逻辑处理解耦，这样我们在开发 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）的示例。