《面向模式的软件架构 第1卷》试读：1.1　模式是什么

很久很久以前，一组随机排列的原子正飘过虚无的太空，它们因受到重创以不同寻常的模式组合在一起。这些组合模式很快学会了自我复制（这正是它们不同寻常之处）并继续飘移，给它们经过的每个星球都带来了巨大的麻烦。这就是宇宙中生命的起源。 ——道格拉斯•亚当斯，《银河系漫游指南》 模式有助于你利用训练有素的软件工程师的集体经验，它们记录了软件开发领域已得到充分证明的既有经验，可帮助推广良好的设计实践。每个模式都阐述了一个在软件系统设计和实现过程中反复出现的问题。利用模式可打造出具有特定特征的软件架构。 软件架构模式是什么呢？模式对软件开发有何帮助呢？本章将深入阐述这两点。 1.1　模式是什么 面对特定问题时，专家很少去寻找与既有解决方案截然不同的新方案，而通常会想起一个以前解决过的类似问题，并将其解决方案的精髓用于解决这个新问题。在建筑[Ale79]、经济学[Etz64]和软件工程 [BJ94] 等众多领域，这种“专家行为”（即“问题—解决方案”的思考方式）已司空见惯。这是一种自然而然的方式，可用于应对任何问题或社交场合[NS72]。 对于这样的问题—解决方案，下面是一个绝佳而直观的例子，它来自建筑领域。 示例　窗户位置[AIS77] 大家都喜欢靠窗户的座位，喜欢在巨大飘窗和低矮窗台前的舒适座椅上落座。在没有这种位置的房间中，你很难感觉舒适或完全放松。 如果房间没有这样的窗户，人就会受到两种作用力的折磨： (1) 既想舒适地坐下来； (2) 又想待在光线充足的地方。 显然，如果舒适的地方（房间内你最想落座的地方）远离窗户，这种矛盾就无法解决。 因此，对于你白天需要长时间待在其中的每个房间，至少得有一个可在旁边舒适落座的窗户。 从特定问题—解决方案中提炼出通用的因素便可得到模式：这些问题—解决方案通常是一系列熟悉的问题和解决方案，其中每对问题—解决方案都呈现出相同的模式[Joh94]。在著作《建筑的永恒之道》中，建筑师Christopher Alexander对模式做了如下定义[Ale79]（247页）。 每个模式都是一条由三部分组成的规则，诠释了特定背景、问题和解决方案之间的关系。 作为现实世界的一个元素，模式阐述了特定背景、该背景下反复出现的一系列作用力以及消解这些作用力的空间配置。 作为一个语言元素，模式提供了指南，指导如何在相关背景下反复利用这种空间配置，以消解一系列给定的作用力。 简而言之，模式既是现实世界中的一件作品，又是如何及何时创作该作品的规则。模式既是流程又是作品：既描述了一件具有生命力的作品，又阐述了该作品的创作流程。 我们发现，存在众多的软件架构模式。这些模式是软件工程专家依靠实践经验摸索出来的，并被用来开发具有特定特征的应用程序。软件工程专家利用模式有效而妥善地解决设计问题。详细讨论这一点之前，先来看一个著名的例子。 示例　Model-View-Controller模式（参见2.4.1节） 来看看开发带人机界面的软件时如何利用这个模式。 用户界面需求容易变化。例如，添加应用程序功能时，必须修改菜单以便能够访问新功能，还可能需要针对特定客户调整用户界面。系统可能需要移植到另一个平台，而该平台采用的“外观”（feel and look）标准完全不同。即便是升级到新的窗口系统版本，也可能需要修改代码。总之，如果系统的使用寿命很长，可能经常需要修改用户界面。 设计灵活的系统时，让用户界面与功能核心紧密地交织在一起将付出高昂的代价，且容易出错。这样做的后果是，可能需要开发和维护多个大不相同的软件系统——每种用户界面实现一个，且修改将涉及众多不同的模块。总之，开发这种交互式软件系统时，必须考虑如下两个方面： 应该能够轻松地修改用户界面，在运行阶段就能完成； 调整或移植用户界面时，不应影响到应用程序功能核心的代码。 为解决这种问题，应将交互式应用程序划分成三部分：处理、输出和输入。 模型（model）组件封装核心数据和功能，独立于输出表示方式和输入行为。 视图（view）组件向用户显示信息。视图从模型那里获取它显示的信息，一个模型可以有多个视图。 每个视图都有相关联的控制器（controller）组件。控制器接受输入，通常是表示鼠标移动、鼠标按钮激活或键盘输入的事件。事件被转换为服务请求，而服务请求要么被发送给模型，要么被发送给视图。用户只通过控制器与系统交互。 通过将模型与视图和控制器组件分开，让同一个模型可以有多个视图。如果用户通过一个视图的控制器修改了模型，这种变更应在依赖相关数据的其他所有视图中反映出来。为此，每当模型的数据发生变化时，它都会通知所有视图，而视图将从模型那里检索新数据，并更新显示的信息。 这种解决方案确保了修改应用程序的一个子系统时不会严重影响其他子系统。例如，可将非图形用户界面改成图形用户界面而无需修改模型子系统，还可支持新的输入设备而不影响信息的显示和功能核心。所有软件版本都可依赖同一个模型子系统，该子系统独立于“外观”。 下面的OMT类图 说明了这种解决方案。 从这个简单示例可知，软件架构模式 具有多个特征。 模式阐述了在特定设计情形下反复出现的问题，并提供了解决方案。在前面的示例中，要解决的问题是允许修改用户界面。开发支持人机交互的软件系统时都可能面临这种问题。要解决这个问题，可将职责完全分离：将应用程序的核心功能与用户界面分离。 模式记录了已得到充分证明的既有设计经验。模式并非刻意发明或创造出来的，而是提炼了经验丰富的从业人员获得的设计知识，并让人能够重用这些知识[GHJV93]。熟悉足够多的模式后，你就可直接应用它们来解决设计问题，而无需做重复的工作[GHJV93]。有了模式，既有知识可供普通读者使用，而不是只留在几个专家的脑海里。利用这些专家的知识，我们可以设计出高品质的软件以完成特定的任务。例如，Model-View-Controller模式提供了大家多年来开发交互式系统获得的经验。很多著名的应用程序都使用了Model-View-Controller模式，这是一种经典架构，众多Smalltalk应用程序和多个应用程序框架（如MacApp [Sch86]和ET++[WGM88]）都采用了这种架构。 模式描述了超越类、实例和组件的抽象[GHJV93]。模式通常描述多个组件、类或对象，并详细说明它们的职责、关系和协作方式。这些组件通力协作，以解决模式阐述的问题，而这通常比使用单个组件更有效。例如，Model-View-Controller模式描述了三个相互协作的组件（MVC），而每个MVC还将与系统的其他MVC协作。 模式提供了一种通用语言，并让大家对设计原则有一致的认识[GHJV93]。精挑细选的模式名将成为广泛传播的设计语言的一部分，有助于对设计问题及其解决方案展开有效的讨论。你只需指出模式名，并解释解决方案的各部分对应的组件或说明各部分之间的关系，而无需对解决方案做长篇大论的解释。例如，从20世纪80年代初开始，名称Model-View-Controller及相应的模式在Smalltalk界就如雷贯耳，并为众多软件工程师所采用。只要说软件采用Model-View-Controller架构，熟悉该模式的同事就马上明白应用程序的基本结构和特征。 模式是一种记录软件架构的手段。模式可描述你在设计软件系统时脑海中浮现的构思，在别人扩展和修改原始架构或修改系统的代码时，这有助于避免违背这种构思。例如，如果知道系统是根据Model-View-Controller模式打造的，就知道如何给系统添加新功能：将核心功能与用户输入和信息显示分开。 模式有助于创建具有指定特征的软件。模式提供了功能行为骨架，有助于实现应用程序的功能。例如，有确保相互协作的组件一致的模式，还有让进程能够透明地对等通信的模式。另外，模式毫不含糊地满足了软件系统的非功能性需求，如可修改性、可靠性、可测试性和可重用性。例如，Model-View-Controller模式有助于提高用户界面的可修改性以及核心功能的可重用性。 模式有助于打造复杂而异质的软件架构。每个模式都描述了一组预定义的组件，这些组件扮演的角色以及它们之间的关系，可用于规范软件结构的特定方面。模式犹如建筑构件，可用于打造更复杂的设计[GHJV93]。使用预先定义好的设计构件有助于提高设计速度和品质。与独自去寻找解决方案相比，应用书写良好的模式可节约时间。模式并不一定比你自己找到的解决方案优秀，但像本书将介绍的模式系统至少有助于评估替代设计方案。 然而，对于特定的设计问题，虽然模式确定了其解决方案的基本结构，但并未指定非常详细的解决方案。模式提供的是一系列问题的通用解决方案纲要，而非可以直接使用的预制模块，你必须根据手头问题的具体需求来实现这个纲要。模式有助于创建类似的部件（unit），这些部件的大致结构可能相似，但呈现出来的外观常常有天壤之别。模式有助于解决问题，但并未提供完整的解决方案。 模式有助于控制软件的复杂度。每个模式都为其阐述的问题提供了经过实践检验的应对之策：需要的组件类型、这些组件扮演的角色、应隐藏的细节、令人瞩目的抽象，以及各个部分的工作原理。面对模式描述的具体设计情形时，没有必要浪费时间去寻找问题的全新解决方案。只要正确实现模式，就可以依靠它提供的解决方案。例如，Model-View- Controller模式有助于将软件系统用户界面的不同方面分离，并为它们提供合适的抽象。 我们对模式的最终定义如下： 软件架构模式描述了在特定设计情形下反复出现的设计问题，并提供了已得到充分证明的通用解决方案摘要。解决方案摘要描述模式的组件、组件的职责和关系，以及这些组件协作的方式。