面向模式构建系统架构

转自IBM developerWorks，想和大家探讨一下有关模式和系统架构方面的内容，欢迎讨论

面向模式构建系统架构

邓辉、孙鸣

架构是一个软件系统中的核心元素，是系统中最难改变的部分，也是构建软件系统中其他部分所依赖的基础，因此系统架构的好坏会从根本上决定基于这个架构所构建的软件系统的质量。系统架构的构建一直是软件开发过程中的一项重要工作，同时也是一项很困难的工作，即便对于很有经验的系统架构师也是如此。但是，模式以及模式语言的提出给出了一条构建系统架构的有效途径，本文将对此进行深入的论述，并以一个著名的单元测试工具JUnit为例进行说明。

概念分析

首先，对架构（architecture）和模式(pattern)这两个概念进行简单的介绍。前面已经讲过，架构是一个系统中的核心元素，是该系统中最本质的部分。系统的各个组成部分正是通过架构所描绘的方式协同工作共同完成系统的功能，从而表现出一个完整的系统。由于系统的本质是不容易变化的，所以如果一个架构构建的正确，也就是说能够真实的反映出系统的本质，那么就可以使基于该架构构建的系统具有比较长的生命力，否则该系统的质量就会逐渐的降级，直至崩溃。如果以建筑领域来作类比可能会比较好理解一些，试想如果一个建筑物构建在一个在结构上有问题的混凝土骨架上，那么该建筑的寿命可想而知是不会长久的。

什么是模式呢？模式是在某种特定的场景(context)下某个不断重复出现的问题的解决方案。模式本身并没有任何的创新性，它仅仅是对于一些已经被证明为优秀的解决方法的归类、总结，目的是为了重用该解决方案而又不用做重复的劳动。其中，"特定场景"和"重复"两个限定词非常关键，"特定场景"给出了什么时候以及为什么使用一个模式，"重复"说明了模式的可重复性从而可以被重用。参考文献〔4〕中总结了23个经典模式，非常值得读者朋友细心研读。

架构搭建的难点

既然架构是一个系统中最核心、最本质的部分，要想构建一个正确的架构当然不会容易，为什么呢？下面将从几个方面进行分析。

首先，由于架构是一个系统中的本质的反映，因此架构一般是由系统中不容易改变的部分组成，这些不容易改变的部分往往是系统中的一些抽象的概念。但是，我们在构建系统的架构前仅仅有一些用户的需求以及对于用户业务流程的用例(use case)，如果缺乏有效的指导原则，很难从这些信息中提取出反映问题领域本质的概念来。关于这一点，参考文献〔3〕中给出了一个很有效的方法：Commonality/Variability（公共性/可变性）分析。它的核心思想是针对问题领域中的概念进行分类，把那些看上去不同但本质上属于一类的概念用一个抽象的概念来表示，然后基于这些抽象的概念构建架构。Commonality/Variability分析方法在发现系统中的抽象概念方面确实很有效，但是前面已经说过，系统架构不仅仅是一些系统中的抽象概念，而且还描绘了这些抽象概念间的关系，仅仅使用Commonality/Variability分析方法不能十分有效的发现抽象概念间的关系。

其次，即使确定了抽象概念间的关系，构建起了一个系统架构，在这个架构的指引下，我们还是很有可能陷入困境。为什么呢？因为该架构可能会缺乏对于我们进一步工作的指引，缺乏后续发现对象的有效手段。也就是说，架构可能过于空泛，缺乏延伸性。

最后，一个经验丰富的系统架构师可能成功的构建了一个系统的架构，成功的基于该架构完成了系统，但是他的经验、心得体会可能会很难为其他的系统架构师所理解，从而在解决同类问题时可以有效的被重用。因为，这些心得体会如果表现的过于抽象，可能会显的空泛从而指导意义不大；如果表现的过于具体，有可能陷入细节从而失去通用性。

正是由于上述原因使得系统架构的构建非常的困难，往往必须由资深的系统架构师来完成。但是随着模式的提出以及对模式研究的深入，这种局面正在逐步的改变。下面让我们先来对模式进行一番深入的认识。

深入认识模式

读者对于模式的认识大都是从《设计模式》（由参考文献[4]翻译而来的）一书的出版开始的。该书中描绘了23个经典的模式，每一个模式都给出了一个精制优雅的解决方案，为每一个程序员所沉迷、拍案叫绝。但是由于经验的不足往往会造成对于模式的误解。《设计模式》一书的作者John Vlissides为此专门写了一片文章进行阐述，详见：http://www.research.ibm.com/designpatterns/pubs/top10misc.pdf。本人在对模式进行深入的研究以及实践的基础上，把对于模式的认识划分为三种境界，下面一一进行说明。

第一层境界：认为模式就是一种解决方案，一般刚刚接触模式的人都处于这个认识层面。确实是这样，刚刚见到模式时很容易被它所提供的精制的解决方案所吸引，由于缺少经验反而容易忽略模式的其它的重要方面。这样做非常容易造成对于模式的误解、误用。比如：为了使用模式而使用模式以及过分的使用模式等。这种境界仅仅认识到模式怎样（How）去解决一个问题。

第二层境界：除了解模式提供的解决方案以外，还能够认识到模式背后的一些指导原则。《设计模式》一书的第一章对于模式背后的一些指导原则进行了详细的论述，比如：针对接口编程；优先使用组合而不是继承；发现变化、封装变化等。不过缺乏经验的人可能对此理解不会深刻，甚至忽略了这些原则，需要不断的实践、体会方能理解。不过体会到这些原则之后就会对面向对象的思想的理解提升一个层次，提高自己的面向对象分析、设计能力。参考文献[2]中对于这些原则有深入细致的讲解，相信会对读者有非常大的帮助。

第三层境界：认识到模式其实是一些关系，用来舒缓系统内部的"冲突力"。这一点仅仅从模式提供的解决方案实例中就可以看出。其实，不管你如何去做，最终的解决方案肯定是一些模块通过彼此的交互、建立一种关系来完成所需的功能。为什么模式提出的方法就是好的呢？就是因为模式给出的关系舒缓了系统内部的"冲突力"，使人感受上去舒服一些。另外，模式并不是简单的给出了一些概念间的关系，它进一步为我们提供了一个场景，提供了进一步工作的指导。是不是太抽象了，我们来举一个例子来说明一下：面向对象设计中有一个著名的原则：SRP（Single Responsibility Principle），即一个类仅仅需要一个职责。如果一个类有多于一个的职责有问题吗？实现起来当然没有问题，但是经验丰富者马上就会感觉到职责间关系的这种"冲突力"，从而感觉到不舒服。反映到实现层面上就是本来毫无关系的模块间依赖过于强，导致代码僵化，牵一发而动全身。"高内聚，松耦合"堪称软件领域处理模块间关系的首要指导原则，但是它没有告诉我们对于一个问题具体该如何去做，模式的出现填充了这个空白，如果我们知道一个模式可以解决我们手头的问题，那么我们就可以非常感性的认识到如何达到"高内聚，松耦合"，因为模式已经给出了这些关系。这一层境界非常抽象，很难达到，有兴趣的读者可以阅读参考文献[1]，相信会有更进一步的认识，更加深入的理解。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有