下面我们就来谈谈模式为什么能够为系统架构的构建带来有效的帮助。

    面向模式构建系统架构

    前面介绍了构建系统架构时的难点，本小节将讲述一下模式如何能够有效的解决这些难题，使得系统架构的构建变得有章可循。

    前面曾经提到过，Commonality/Variability分析方法可以有效的发现反映问题领域本质的概念，但是不能十分有效的发现抽象概念间的关系。如果Commonality/Variability分析方法和模式结合起来，就能够有效的解决这个问题。上一小节也说过，模式其实就是一些关系。如果我们有一些需求，并且我们知道有针对该需求的模式，那么我们就可以通过Commonality/Variability分析方法发现反映问题领域本质的概念，然后根据可用的模式去建立这些概念之间的关系来实现我们的需求。这样我们就可以通过模式有效的克服不能有效确定概念间关系的难点。
   
    模式本身并不仅仅简单是一些关系，它还具有深刻的内涵。它具有自身的意图、动机、适用性以及核心解决方案等众多的内容。一旦我们确定使用了一个模式，那么这个模式就为我们搭建了一个内容丰富的场景，这个场景可以非常有效的指导我们进一步的工作，启发我们发现新的对象。这样，基于模式构建的系统架构就变得抽象（模式本身就是一些抽象的关系）而不空泛并且具有很好的延伸性。

    模式也提供了一套公认非常有效的记录方法，可以把自己经过反复验证的解决方案记录下来传授给其他人重用，即模式具有可传授性。这样，有经验的系统架构师就可以把自己的一些心得体会通过模式的方法记录下来，就可以克服经验无法有效传授的问题。

    其实很多模式本身就是针对系统架构提出的，比如：MVC（Model-View-Controller），它是专门针对交互系统提出的，所以如果我们要构建一个交互系统，那么我们就可以直接应用MVC模式，然后在该模式所搭建的场景的启发下去发现Model、View以及Controller，在这个大的场景的指导下根据其它的需求（模式）构建一些小的场景对系统进行有效的分化。细心的读者会发现，模式和系统架构有很大的相似性，都是处理一些抽象概念间的关系，但是二者还是有很大的不同的，模式是领域无关的，它是解决一些抽象问题的，但是系统架构是针对我们要解决的实际问题的，是领域相关的。我们可以通过对问题领域的分析、分解，找到和我们要解决的问题匹配的模式，对该模式进行定制应用到我们的系统中来。把模式结合在一起构建起整个系统架构来。

    面向模式构建的系统架构在需求发生变化时还会使我们处于一个非常有利的位置。为什么呢？因为模式是针对一个反复出现的问题的优秀的解决方案，它的方法就是发现变化、封装变化。它本身已经充分考虑了变化的情况。模式采用了一种不同的对待变化的方法，它不是预先考虑会如何变化，而是考虑哪里可能会变化，然后隔离，所以当变化发生时我们就处于一个有利的位置上。

    最后让我们来看看模式论坛研究、探讨的一个焦点论题：模式的生成性。模式的生成能力是指模式创建最终行为的能力。有人认为，模式系统可以形成一种语言，即模式语言。模式既是模式语言的要素，同时又是模式语言的规则。象数学证明一样，可以通过模式的推导、演绎生成系统架构。当然，目前的模式语言远远还不完备，还不具有如此强大的生成能力。不过，至少为我们的软件开发的永恒解决方法提出了一个美好的希望，让我们大家共同来为此努力。有兴趣的读者可以到hillside.net获得更多有关模式语言的信息。

    JUnit架构一览

    前面讲了这么多，本小节我们将结合一个实例进行说明。我所选择的是JUnit，一个很著名的单元测试工具，选择它作为例子主要有两个原因：其一是JUnit相对比较简单，这样我可以集中于要论述的主题；其二是JUnit中大量使用了模式，这样大家可以对于上面的论述有一个感性的认识。下面对于JUnit的说明会比较粗略，读者可以到www.junit.org去了解有关JUnit的更加详细的信息。

    JUnit是一个单元测试工具，所以它就要满足使用者对于单元测试工具的需求。让我们一一来进行说明，首先测试用例的书写必须要容易，只有这样大家才可能会使用该测试工具。要迎合这一点，我们可以通过把测试用例表示为对象的方式来完成，对象的概念和人思维中的概念最为贴近，表示起来也最为自然。Command非常符合我们的要求，看看它的意图：将一个请求封装成一个对象，从而对请求进行排队或者记录日志…。另外，测试工具要为使用者做它能够做的最多的事情，尽量减少使用者的工作量，我们必须对测试的一般流程进行分析，归纳出一个模板流程，这样就可以使使用者仅仅关注自己所需要的具体步骤而不用考虑如何去组织这些步骤（一般的测试都分为测试准备即setUp，运行测试即runTest以及结束清除即tearDown阶段），Template Method模式正好能够帮上忙。另外，测试工具应该能够统一处理单独的用例以及多个用例的组合，这样也可以大大减少使用者的工作量，是不是马上就想到了Composite模式，不错，就是它。

    Junit本身提供了源代码，有兴趣的读者朋友可以参阅。不过如果了解了系统的架构后在去看源代码的话，相信会有不同的感受。

    结论

    本文从宏观上探讨了系统架构、模式以及模式在构建系统架构方面的的有效性。限于篇幅，其中有很多重要的内容没有做十分深入的论述，关于这些内容准备在后续的文章中作为独立的主题来讲解。希望本文能为读者朋友带来一些启发。最后我就以模式的提出者Christopher Alexander的一段具有深刻内涵的话作为结束："以一种松散的方式把一些模式串接起来建造建筑是可能的。这样的建筑仅仅是一些模式的堆砌，而不紧凑，这不够深刻。然而另有一种组合模式的方式，许多模式重叠在一个物理空间里，这样的建筑非常紧凑，在一小块空间里集成了许多的内涵，由于这种紧凑，它变得深刻。"

    参考文献

    The Timeless Way of Building, Christopher Alexander
    Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan Shalloway and James R. Trott
    Multi-Paradigm Design for C++, James O. Coplien
    Design Patterns, Gamma, et. al.,