软件的架构与模式之经典架构模式简介

根据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模式。

现代的软件系统都是比较复杂的，设计模式的任务就是协助设计师处理复杂系统的设计。

设计师处理复杂系统的一个常见方法便是将其"分而治之"，把一个系统划分为几个较小的子系统。但是这样做了以后，设计师往往仍然会发现一个子系统内仍然有太多的类型要处理。而使用一个子系统的使用端往往只关注一些特定的功能，却要同时与子系统内部的许多对象打交道后才能达到目的，请见下面的对象图。

图4、Facade架构模式的结构图。

这就是一种不便，它使得系统的逻辑变得不必要的复杂，维护成本提高，复用率降低。

用一个范例说明，中国大陆的医院便是一个子系统，按照部门职能，这个系统可以划分为挂号、门诊、划价、化验、收银、取药等。看病的病人要与这些部门打交道，就如同一个子系统的使用端与一个子系统的各个类型打交道一样，不是一件容易的事情。

首先病人必须先挂号，然后门诊。如果医生要求化验，病人必须首先划价，然后缴款，才能到化验部门做化验。化验后，再回到门诊室，请见下面的对象图。

图5、描述病人在医院里的体验。图中的方框代表医院。

解决这种不便的方法便是引进Facade模式。仍然通过医院的范例说明，可以设置一个接待员的位置，由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是Facade模式的体现，病人只接触接待员，由接待员负责与医院的各个部门打交道，请见下面的对象图。

图6、描述经过Facade模式的改装后，病人在医院里的体验。图中的方框代表医院。

Facade模式要求一个子系统的外部与其内部的通讯必须通过一个统一的门面（Facade）对象进行。Facade模式提供一个高等级的接口，使得子系统更易于使用。

使用了Facade模式之后，本章的第一个图中所描述的一个子系统的使用端对象所面对的复杂关系就可以简化为下面这个样子。

图7、Facade架构模式的结构图

描述经过Facade模式的改装后，一个子系统的使用端与子系统的关系。图中的大方框代表一个子系统。

就如同医院的接待员一样，Facade模式的门面类型将使用端与子系统的内部复杂性分隔开，使得使用端只需要与门面对象打交道，而不需要与子系统内部的很多对象打交道。