软件的架构与模式之经典架构模式简介
根据Linda Rising的《Pattern Almanac》一书，已知的架构模式有七十多种。这是一个只多不少的统计，其中包括了很多通常认为是设计模式的模式，比如Bridge，Facade，Interpreter，Mediator等模式通常认为是设计模式，但是在许多情况下，也可以作为架构模式出现，因此也常常被当作架构模式。
Layers架构模式
在收集到用户对软件的要求之后，架构设计就开始了。架构设计一个主要的目的，就是把系统划分成为很多"板块"。划分的方式通常有两种，一种是横向的划分，一种是纵向划分。
横向划分将系统按照商业目的划分。比如一个书店的管理系统可以划分成为进货、销售、库存管理、员工管理等等。
纵向划分则不同，它按照抽象层次的高低，将系统划分成"层"，或叫Layer。比如一个公司的内网管理系统通常可以划分成为下面的几个Layer:
一、网页，也就是用户界面，负责显示数据、接受用户输入；
二、领域层，包括JavaBean或者COM对象、B2B服务等，封装了必要的商业逻辑，负责根据商业逻辑决定显示什么数据、以及如何根据用户输入的数据进行计算；
三、数据库，负责存储数据，按照查询要求提供所存储的数据。
四、操作系统层，比如Windows NT或者Solaris等
五、硬件层，比如SUN E450服务器等
有人把这种Layer叫做Tier，但是Tier多带有物理含义，不同的Tier往往位于不同的计算机上，由网络连接起来，而Layer是纯粹逻辑的概念，与物理划分无关。
Layers架构模式的好处是：
第一、任何一层的变化都可以很好地局限于这一层，而不会影响到其他各层。
第二、更容易容纳新的技术和变化。Layers架构模式容许任何一层变更所使用的技术
Fa?ade架构模式
外部与一个子系统的通讯必须通过一个统一的门面（Facade）对象进行，这就是Facade模式。
现代的软件系统都是比较复杂的，设计模式的任务就是协助设计师处理复杂系统的设计。
设计师处理复杂系统的一个常见方法便是将其"分而治之"，把一个系统划分为几个较小的子系统。但是这样做了以后，设计师往往仍然会发现一个子系统内仍然有太多的类型要处理。而使用一个子系统的使用端往往只关注一些特定的功能，却要同时与子系统内部的许多对象打交道后才能达到目的，请见下面的对象图。
这就是一种不便，它使得系统的逻辑变得不必要的复杂，维护成本提高，复用率降低。
用一个范例说明，中国大陆的医院便是一个子系统，按照部门职能，这个系统可以划分为挂号、门诊、划价、化验、收银、取药等。看病的病人要与这些部门打交道，就如同一个子系统的使用端与一个子系统的各个类型打交道一样，不是一件容易的事情。
首先病人必须先挂号，然后门诊。如果医生要求化验，病人必须首先划价，然后缴款，才能到化验部门做化验。化验后，再回到门诊室，请见下面的对象图。
解决这种不便的方法便是引进Facade模式。仍然通过医院的范例说明，可以设置一个接待员的位置，由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是Facade模式的体现，病人只接触接待员，由接待员负责与医院的各个部门打交道，请见下面的对象图。
Facade模式要求一个子系统的外部与其内部的通讯必须通过一个统一的门面（Facade）对象进行。Facade模式提供一个高等级的接口，使得子系统更易于使用。
使用了Facade模式之后，本章的第一个图中所描述的一个子系统的使用端对象所面对的复杂关系就可以简化为下面这个样子。
描述经过Facade模式的改装后，一个子系统的使用端与子系统的关系。图中的大方框代表一个子系统。
就如同医院的接待员一样，Facade模式的门面类型将使用端与子系统的内部复杂性分隔开，使得使用端只需要与门面对象打交道，而不需要与子系统内部的很多对象打交道。
Mediator架构模式
Mediator模式包装了一系列对象相互作用的方式，使得这些对象不必互相明显参照；从而使它们可以较松散地耦合。当这些对象中的某些对象之间的相互作用发生改变时，不会立即影响到其它的一些对象之间的相互作用；从而可以保证这些相互作用可以彼此独立地变化。
在下面的示意图中有大量的对象，这些对象既会影响别的对象，又会被别的对象所影响，因此常常叫做同事（Colleague）对象。这些同事对象通过彼此的相互作用形成系统的行为。从图中可以看出，几乎每一个对象都需要与其它的对象发生相互作用，而这种相互作用表现为一个对象与另一个对象的直接耦合。
通过引入调停者对象（Mediator），可以将系统的网状结构变成以中介者为中心的星形结构，如下图所示。在这个星形结构中，同事对象不再通过直接的联系与另一个对象发生相互作用；相反地，它通过调停者对象与另一个对象发生相互作用。调停者对象的存在保证了对象结构上的稳定，也就是说，系统的结构不会因为新对象的引入造成大量的修改工作。
比较传统的设计方法，面向对象的技术可以更好地协助设计师管理更为复杂的系统。一个好的面向对象的设计可以使对象之间增加协作性（Collaboration），减少耦合度（Coupling）。一个深思熟虑的设计会把一个系统分解为一群相互协作的同事对象，然后给每一个同事对象以独特的责任，恰当的配置它们之间的协作关系，使它们可以在一起工作。
在Mediator模式中，所有的成员对象都可以协调工作，但是又不直接相互管理。这些对象都与一个处于中心地位的调停者对象发生紧密的关系，由这个调停者对象进行协调工作。这个协调者对象叫做调停者（Mediator），而调停者所协调的成员对象称做同事（Colleague）对象。
在Colleague对象内部发生的事件会影响到所有的同事，但是这种影响不是以直接管理的方式直接传到其它的对象上的。记住在小组的成员增加时，这样的相互作用关系是以比指数更快的方式增加的。相反，这种影响仅仅直接影响到调停者对象，而调停者对象反过来会协调其它的同事，形成整个系统的行为。
如果小组的成员增加时，调停者对象可能会面临修改，而其它的同事则可以装做不知道这个新的成员一样，不必修改。反过来，如果小组的成员之一被从系统中删除的话，调停者对象需要对此做出修改，而小组中其它的同事则不必改动。
Interpreter架构模式
给定一个语言之后，Interpreter模式可以定义出其文法的一种表示，并同时提供一个直译器；使用端可以使用这个直译器来解释这个语言中的句子。
如果某一类型问题一再地发生的话，那么一个有意义的做法就是将此类型问题的各个实例表达为一个简单语言中的语句。这样就可以建造一个直译器，通过解释这些语句达到解决问题的目的。
例如，依照一个匹配模式搜寻字符串便是一个常见的问题。与其为每一个匹配模式建造一个特定的算法，不如建造一个一般性的算法处理各种常规表达式。当接到一个指定的常规表达式时，系统使用一个直译器解释这个常规表达式，从而对字符串进行匹配。
再比如VBA（Visual Basic for Applications）就不仅仅出现在微软的Office系列软件中，并且可以供第三厂家出产的软件嵌入使用；Crystal Reports报表生成软件也包括了一个便于使用的宏语言，使用户可以执行较为复杂的命令操作。一般而言，将VBA或者其它的语言软件嵌入到自己的软件产品中，可以使产品定制化（Customization）能力大大增强，但是这些宏语言引擎往往都很昂贵。
现在要介绍的Interpreter模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。熟悉了这个模式以后，一个没有接收过形式语言和编译器的正规训练的设计师也可以自行设计一个简单的直译器，以便为使用端提供一个简单语言，或者在系统内部使用一个简单语言描述一个合适的问题。
语言、直译器和剖析器
Interpreter模式只描述直译器是怎样工作的，并不指明怎样在执行时创建新的直译器。虽然广义地讲直译器不一定要有一个剖析器（Parser），但是使用剖析器仍然是最常见的建立直译器的办法。一个剖析器可以从一个档或命令行读入文字性命令，并创建直译器。
剖析器是一种能够识别文字并将文字按照一定规则进行分解以便进一步处理的对象。剖析器能够识别的字符串叫做语言。通常建立的小型计算机语言是与环境无关的语言，也就是遵循一定的文法的文字模式，所谓文法，便是决定怎样将语言的元素组合起来的规则的集合。剖析器便是根据组合规则将字符串分解的。
抽象地讲，语言并不一定是以字符串的形式表达的。在Interpreter模式里面所提到的语言是指任何直译器对象能够解释的任何组合。在Interpreter模式中，需要定义一个代表文法的命令类型的等级结构，也就是一系列的组合规则；每一个命令对象都有一个解释方法，代表对命令对象的解释。
命令对象的等级结构中的对象的任何排列组合都是一个语言，而剖析器的工作便是将一个文字性语言翻译成为等效的直译器语言。因此，直译器往往需要剖析器。
认识Jack吗？
剖析器生成器（Parser Generator），常常称为编译器的编译器（Compiler Complier）。Sun Microsystem提供一个专为Java程序员发明的强大的剖析器生成器，最初叫做Jack，后来改名为JavaCC。
要使用JavaCC，必须使用它提供的脚本语言编写一个脚本，然后执行JavaCC生成Java源代码。这生成的源代码就是所需的剖析器。现在Sun已经不再负责JavaCC的研发，对JavaCC感兴趣的读者可以从http://www.experimentalstuff.com/Technologies/JavaCC得到免费的JavaCC和相关数据。
JavaCC最早命名为Jack是为了与一个早就广泛使用的剖析器生成器YACC谐音。如果读者已经熟悉了YACC，可以使用YACC达到同样的目的；只是相比之下JavaCC更容易得到Java程序员的喜爱。
Layers架构模式
在收集到用户对软件的要求之后，架构设计就开始了。架构设计一个主要的目的，就是把系统划分成为很多"板块"。划分的方式通常有两种，一种是横向的划分，一种是纵向划分。
横向划分将系统按照商业目的划分。比如一个书店的管理系统可以划分成为进货、销售、库存管理、员工管理等等。
纵向划分则不同，它按照抽象层次的高低，将系统划分成"层"，或叫Layer。比如一个公司的内网管理系统通常可以划分成为下面的几个Layer:
一、网页，也就是用户界面，负责显示数据、接受用户输入；
二、领域层，包括JavaBean或者COM对象、B2B服务等，封装了必要的商业逻辑，负责根据商业逻辑决定显示什么数据、以及如何根据用户输入的数据进行计算；
三、数据库，负责存储数据，按照查询要求提供所存储的数据。
四、操作系统层，比如Windows NT或者Solaris等
五、硬件层，比如SUN E450服务器等
有人把这种Layer叫做Tier，但是Tier多带有物理含义，不同的Tier往往位于不同的计算机上，由网络连接起来，而Layer是纯粹逻辑的概念，与物理划分无关。
Layers架构模式的好处是：
第一、任何一层的变化都可以很好地局限于这一层，而不会影响到其他各层。
第二、更容易容纳新的技术和变化。Layers架构模式容许任何一层变更所使用的技术
Fa?ade架构模式
外部与一个子系统的通讯必须通过一个统一的门面（Facade）对象进行，这就是Facade模式。
现代的软件系统都是比较复杂的，设计模式的任务就是协助设计师处理复杂系统的设计。
设计师处理复杂系统的一个常见方法便是将其"分而治之"，把一个系统划分为几个较小的子系统。但是这样做了以后，设计师往往仍然会发现一个子系统内仍然有太多的类型要处理。而使用一个子系统的使用端往往只关注一些特定的功能，却要同时与子系统内部的许多对象打交道后才能达到目的，请见下面的对象图。
 图4、Facade架构模式的结构图。 |
这就是一种不便，它使得系统的逻辑变得不必要的复杂，维护成本提高，复用率降低。
用一个范例说明，中国大陆的医院便是一个子系统，按照部门职能，这个系统可以划分为挂号、门诊、划价、化验、收银、取药等。看病的病人要与这些部门打交道，就如同一个子系统的使用端与一个子系统的各个类型打交道一样，不是一件容易的事情。
首先病人必须先挂号，然后门诊。如果医生要求化验，病人必须首先划价，然后缴款，才能到化验部门做化验。化验后，再回到门诊室，请见下面的对象图。
 图5、描述病人在医院里的体验。图中的方框代表医院。 |
解决这种不便的方法便是引进Facade模式。仍然通过医院的范例说明，可以设置一个接待员的位置，由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是Facade模式的体现，病人只接触接待员，由接待员负责与医院的各个部门打交道，请见下面的对象图。
Facade模式要求一个子系统的外部与其内部的通讯必须通过一个统一的门面（Facade）对象进行。Facade模式提供一个高等级的接口，使得子系统更易于使用。
使用了Facade模式之后，本章的第一个图中所描述的一个子系统的使用端对象所面对的复杂关系就可以简化为下面这个样子。
 图7、Facade架构模式的结构图 |
描述经过Facade模式的改装后，一个子系统的使用端与子系统的关系。图中的大方框代表一个子系统。
就如同医院的接待员一样，Facade模式的门面类型将使用端与子系统的内部复杂性分隔开，使得使用端只需要与门面对象打交道，而不需要与子系统内部的很多对象打交道。
Mediator架构模式
Mediator模式包装了一系列对象相互作用的方式，使得这些对象不必互相明显参照；从而使它们可以较松散地耦合。当这些对象中的某些对象之间的相互作用发生改变时，不会立即影响到其它的一些对象之间的相互作用；从而可以保证这些相互作用可以彼此独立地变化。
在下面的示意图中有大量的对象，这些对象既会影响别的对象，又会被别的对象所影响，因此常常叫做同事（Colleague）对象。这些同事对象通过彼此的相互作用形成系统的行为。从图中可以看出，几乎每一个对象都需要与其它的对象发生相互作用，而这种相互作用表现为一个对象与另一个对象的直接耦合。
 图8、这是一个过度耦合的系统 |
通过引入调停者对象（Mediator），可以将系统的网状结构变成以中介者为中心的星形结构，如下图所示。在这个星形结构中，同事对象不再通过直接的联系与另一个对象发生相互作用；相反地，它通过调停者对象与另一个对象发生相互作用。调停者对象的存在保证了对象结构上的稳定，也就是说，系统的结构不会因为新对象的引入造成大量的修改工作。
 图9、这是一个使用了Mediator架构模式之后的结构图 |
比较传统的设计方法，面向对象的技术可以更好地协助设计师管理更为复杂的系统。一个好的面向对象的设计可以使对象之间增加协作性（Collaboration），减少耦合度（Coupling）。一个深思熟虑的设计会把一个系统分解为一群相互协作的同事对象，然后给每一个同事对象以独特的责任，恰当的配置它们之间的协作关系，使它们可以在一起工作。
在Mediator模式中，所有的成员对象都可以协调工作，但是又不直接相互管理。这些对象都与一个处于中心地位的调停者对象发生紧密的关系，由这个调停者对象进行协调工作。这个协调者对象叫做调停者（Mediator），而调停者所协调的成员对象称做同事（Colleague）对象。
在Colleague对象内部发生的事件会影响到所有的同事，但是这种影响不是以直接管理的方式直接传到其它的对象上的。记住在小组的成员增加时，这样的相互作用关系是以比指数更快的方式增加的。相反，这种影响仅仅直接影响到调停者对象，而调停者对象反过来会协调其它的同事，形成整个系统的行为。
如果小组的成员增加时，调停者对象可能会面临修改，而其它的同事则可以装做不知道这个新的成员一样，不必修改。反过来，如果小组的成员之一被从系统中删除的话，调停者对象需要对此做出修改，而小组中其它的同事则不必改动。
Interpreter架构模式
给定一个语言之后，Interpreter模式可以定义出其文法的一种表示，并同时提供一个直译器；使用端可以使用这个直译器来解释这个语言中的句子。
如果某一类型问题一再地发生的话，那么一个有意义的做法就是将此类型问题的各个实例表达为一个简单语言中的语句。这样就可以建造一个直译器，通过解释这些语句达到解决问题的目的。
例如，依照一个匹配模式搜寻字符串便是一个常见的问题。与其为每一个匹配模式建造一个特定的算法，不如建造一个一般性的算法处理各种常规表达式。当接到一个指定的常规表达式时，系统使用一个直译器解释这个常规表达式，从而对字符串进行匹配。
再比如VBA（Visual Basic for Applications）就不仅仅出现在微软的Office系列软件中，并且可以供第三厂家出产的软件嵌入使用；Crystal Reports报表生成软件也包括了一个便于使用的宏语言，使用户可以执行较为复杂的命令操作。一般而言，将VBA或者其它的语言软件嵌入到自己的软件产品中，可以使产品定制化（Customization）能力大大增强，但是这些宏语言引擎往往都很昂贵。
现在要介绍的Interpreter模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。熟悉了这个模式以后，一个没有接收过形式语言和编译器的正规训练的设计师也可以自行设计一个简单的直译器，以便为使用端提供一个简单语言，或者在系统内部使用一个简单语言描述一个合适的问题。
语言、直译器和剖析器
Interpreter模式只描述直译器是怎样工作的，并不指明怎样在执行时创建新的直译器。虽然广义地讲直译器不一定要有一个剖析器（Parser），但是使用剖析器仍然是最常见的建立直译器的办法。一个剖析器可以从一个档或命令行读入文字性命令，并创建直译器。
剖析器是一种能够识别文字并将文字按照一定规则进行分解以便进一步处理的对象。剖析器能够识别的字符串叫做语言。通常建立的小型计算机语言是与环境无关的语言，也就是遵循一定的文法的文字模式，所谓文法，便是决定怎样将语言的元素组合起来的规则的集合。剖析器便是根据组合规则将字符串分解的。
抽象地讲，语言并不一定是以字符串的形式表达的。在Interpreter模式里面所提到的语言是指任何直译器对象能够解释的任何组合。在Interpreter模式中，需要定义一个代表文法的命令类型的等级结构，也就是一系列的组合规则；每一个命令对象都有一个解释方法，代表对命令对象的解释。
命令对象的等级结构中的对象的任何排列组合都是一个语言，而剖析器的工作便是将一个文字性语言翻译成为等效的直译器语言。因此，直译器往往需要剖析器。
认识Jack吗？
剖析器生成器（Parser Generator），常常称为编译器的编译器（Compiler Complier）。Sun Microsystem提供一个专为Java程序员发明的强大的剖析器生成器，最初叫做Jack，后来改名为JavaCC。
要使用JavaCC，必须使用它提供的脚本语言编写一个脚本，然后执行JavaCC生成Java源代码。这生成的源代码就是所需的剖析器。现在Sun已经不再负责JavaCC的研发，对JavaCC感兴趣的读者可以从http://www.experimentalstuff.com/Technologies/JavaCC得到免费的JavaCC和相关数据。
JavaCC最早命名为Jack是为了与一个早就广泛使用的剖析器生成器YACC谐音。如果读者已经熟悉了YACC，可以使用YACC达到同样的目的；只是相比之下JavaCC更容易得到Java程序员的喜爱。
