这个模式是一种架构模式，模式的定义有三个要素：问题，环境，解决方案，这在前面我们已经详细地论述过了，在这里我们讨论一下其他的参量。每个模式都有它自己独特的价值观，那么界面组装器模式给我们提供了什么样的价值观呢?

　　首先，它的精髓在于这种分解界面，将界面和组装行为解耦的设计思想，这在拥有多个界面的应用中很有益处，当界面多的时候，如果没有一个比较集中的调度控制方式来对这些界面进行管理，就会形成界面行为无法规范，风格各异，更难以作 transaction 事务或 session 会话控制。这在小型应用开发中也许不很明显，但在一个大中型应用中对分散的不规范的界面行为进行控制将会是一场恶梦，到最后可能整个开发组都沉浸于 bug 的修复和界面修改中，而无暇顾及领域逻辑代码的编写。而通过将界面和组装行为解耦就可以让开发人员集中精力于界面逻辑和领域逻辑的开发，而不用每一个界面都去编写管理界面的代码。其实这也是模式化的一个优点，模式可以优化我们的架构，可以规范开发行为，因此也会节省开发成本。

　　其二，它将界面逻辑处理与领域逻辑处理(也就是数据逻辑处理)解耦。我们将数据输入输出从界面模型中抽取出来，没有与界面耦合在一起，这就获得巨大的好处，第一，我们可以在界面之外来处理数据，在我们的领域类中处理这些数据，也就是说界面只是提供了一个定义数据的载体，而这些数据是被领域逻辑类使用的，而我们开发的主要精力也应该放在处理业务逻辑的领域类上。第二，现在我们将界面和领域类解耦，这样我们的界面和领域类都可以独立地变化，相互之间没有任何依赖，这就很方便于我们开发人员的分工，编写界面的开发组不用依赖于编写后台逻辑类的开发组。第三，在做单元测试-unit test 时，开发后台逻辑类的人员可以单独测试领域类，而开发界面的人员也可以单独测试界面逻辑。第四，当我们有多套界面机制时，我们的后台逻辑类可以很方便地接插上去，比如我们要支持 GUI(SWT/Java Swing)和 Web 方式，那么我们的领域类和数据类无需任何更改就可以方便的切换。第五，我们还能获得好处，就是数据类的可重用，如果我们没有输入输出数据类的封装行为，那可能我们会将各条数据散落在界面类中直接处理，这样当你要换一种界面机制时就必须重写这部分逻辑，无法重用。

　　作为一种模式，它会有很多的变体，也就是说它不拘泥于我们给出的这种外在实现方式，它还有其它的实现，例子中我们只是组装一个 EditorComposite，我们当然可以一次组装几个 EditorComposite，比如一个复杂的界面会有好几个 EditorComposite 组成，或者像属性页，并列着有好几个 EditorComposite，我们只需要自己实现一个组装器类 Assembler 就可以。又或者我们可以在运行界面时动态地在几个界面之间切换界面，这可能会复杂一些，也受限于平台或语言的技术实现，但也并非不可实现。

　　对于该模式的适用性，我想它主要适用于那些每次装载一个 EditorComposite 或属性页的情况，至于是否可以作为 Wizard 向导界面的实现架构，还需进一步探索，不过从这个模式的概念层次上来看，它的关键的价值观是完全可以用于实现 Wizard 向导界面的，只不过具体实现时可能会对现在的架构变动较大。另外这个模式主要适用于 GUI 客户端界面，对于 Web 形式的界面，已经有别的模式可以考虑。

　　我们还可以讨论一下界面组装器模式与别的模式之间的关系。在界面架构界我们已经有了大名鼎鼎的 MVC 模式，为什么还需要界面组装器模式呢?虽然 MVC 模式解决的也是界面与领域逻辑处理的解耦，但它的出发点主要是针对一个业务逻辑处理后会有好几个界面同时需要更新显示，也就是说它的贡献在于他的及时传播数据变更的能力，这和我们的模式是不一致的，我们主要解决界面的分解组装和数据剥离的问题，当然他们在结构上有些相似之处，我们的 EditorFacade 有点像 MVC 中的控制器。

　　结束语

　　本文所讲述的界面组装器模式为我们提供了将界面和组装行为解耦，将界面逻辑处理与领域逻辑处理解耦的价值观，在 GUI 胖客户端型界面中可以大量应用，笔者已经在几个大型项目中应用了它，所以它的可行性是经过实践检验的。当然，任何模式，不管是设计模式还是架构模式，都有它的适用性，只有合适的，没有绝对的优劣，我们是否应用模式是在于模式为我们提供的价值观是否和我们的需求期望符合，而不是因为别的原因。