软件设计模式的非软件例子（三）

行为模式－－描述类和对象怎样交互和怎样分配职责

  作者总结了十一种行为模式。这些模式可以在硬币分类银行、餐馆订餐、音乐、运输、汽车修理、自动售货机和家庭建筑中找到例子。

 职责链（Chain of Responsibility）举例

   职责链模式使得多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。机械硬币分拣银行使用职责链。这里并不是为每一种硬币分配一个滑槽，而是仅使用一个滑槽。当硬币落下时，硬币被银行内部的机械导向至适当的接收盒。

 

  图 13 ： 使用硬币分拣例子的职责链模式对象图

 

 命令（Command）模式

    命令模式将一个请求封装为一个对象，从而使你可以使用不同的请求对客户进行参数化。用餐时的账单是命令模式的一个例子。服务员接受顾客的点单，把它记在账单上封装。这个点单被排队等待烹饪。注意这里的“账单”是不依赖于菜单的，它可以被不同的顾客使用，因此它可以添入不同的点单项目。（关于这个实例的详细解析见我的那篇 从“在快餐店吃饭”到Command模式(一)）

 

  图 14 ：使用用餐例子的命令模式对象图

 

解释器（Interpreter）举例

    解释器模式定义了特定语言的文法表示和解释该文法的解释器。音乐家是解释器的例子。音阶和它的持续时间可以用五线谱上的符号表示。这些符号就是音乐语言[14]。音乐家按照乐谱演奏，就可以反复重现同样的音乐。

 

 

图 15：使用音乐例子的解释器模式对象图

 

  迭代器（Iterator）举例

 

  迭代器提供一种方法顺序访问一个集合对象中各个元素，而又不需要暴露该对象的内

 

部表示。在早期的电视机中，一个拨盘用来改变频道。当改变频道时，需要手工转动

 

拨盘移过每一个频道，而不论这个频道是否有信号。现在的电视机，使用[后一个]和[前

 

一个]按钮。当按下[后一个]按钮时，将切换到下一个预置的频道。想象一下在陌生的城

 

市中的旅店中看电视。当改变频道时，重要的不是几频道，而是节目内容。如果对一

 

个频道的节目不感兴趣，那么可以换下一个频道，而不需要知道它是几频道。

    

     

 

图 16 ：使用选频器作例子的迭代模式对象图

 

中介者（Mediator）举例

    中介者模式用一个中介对象来控制一系列的对象交互。通过中介者实现各个对象之间的松散耦合，而不是彼此直接作用。机场的控制塔很好地演示了这种模式。降落或者起飞的飞机直接与塔台通讯，而不是彼此间直接通讯。谁可以起飞或降落是由塔台决定的。这里需要注意的是塔台并不控制整个飞行过程。它只负责飞机在机场附近的区域。

 

 

 

 

 

 

   图 17 ：使用训练中心为例子的中介者模式

 

  备忘录（Memento）举例

    备忘录模式捕获并且在外部保存一个对象的内部状态，使得以后可以将对象恢复到该状态。这种模式通常体现在你自己修理汽车的刹车时。首先移开两边的挡板，露出左右刹车片。只能卸下一片，这时另一片作为一个备忘录来表明刹车是怎样安装的。在这片修理完成后，才可以卸下另一片。当第二片卸下时，第一片就成了备忘录。

   

 

  图 18 ：使用刹车片例子的备忘录模式对象图

 

观察者（Observer）模式

    观察者定义了对象间一对多的关系，当一个对象的状态变化时，所有依赖它的对象都得到通知并且自动地更新。拍卖演示了这种模式。每个投标人都有一个标有数字的牌子用于出价。拍卖师开始拍卖时，他观察是否有牌子举起出价。每次接受一个新的出价都改变了拍卖的当前价格，并且广播给所有的投标人进行新的出价。（有关观察者模式在我的那篇“倾听来自观察者模式中两个成员的经典对话。。。”有详细介绍）

  

 

  图 19 ：使用拍卖例子的观察者模式

 

 状态（State）模式

      状态模式允许一个对象在其内部状态改变时改变它的行为。这种模式可以在自动售货机上观察到。自动售货机的状态包括列商品清单，收款，找钱和选择商品等几种状态。当投入硬币并选择了一个商品时，自动售货机可以完成以下几种操作，包括：送出商品不找钱、送出商品并找钱、由于投币不足不送出商品、由于商品售完不送出商品。

 

 

 

图 20 ：使用自动售货机例子的状态模式对象图

 

 策略（Strategy）模式

     策略模式定义了一系列可以相互替换的算法。不同的到飞机场去的方式就是一个策略模式的例子。有几种选择：自己开车、坐出租车、乘机场班车、乘公共汽车或使用专车服务等等。对于某些机场，地铁和直升机也是可能的选择。任何一种方式都可以把你送到机场，它们可以相互代替。你必须根据价格、便利性和时间做出选择。

 

   

 

 

  图 21 ：使用去机场作为例子的策略模式对象图

 

  模板方法（Template Method）举例

     模板方法定义了一个操作中算法的骨架，而将一些步骤延迟到子类中。房屋建筑师在开发新项目时会使用模板方法。一个典型的规划包括一些建筑平面图，每个平面图体现了不同部分。在一个平面图中，地基、结构、上下水和走线对于每个房间都是一样的。只有在建筑的后期才开始有差别而产生了不同的房屋样式。

 

   

 

  图 22 ：使用建筑平面图为例子的模板方法模式

 

 访问者（Visitor）举例

    访问者模式表示一个作用于对象结构中各元素的操作，定义这个操作并不会改变元素的类。这种模式可以在出租车公司的运转中观察到。当一个人给出租车公司打电话时，他（她）就成了公司所有顾客的一员。然后公司指定一辆车去服务（接受访问者）。在进入出租车之后，这个人（访问者）就不再控制他（她）的旅程了，而是由出租车（驾驶员）负责。

  

 

 

  图 23 ：使用出租车例子的观察者模式对象图

 

意义

     作者已经表明了软件设计模式的非软件例子的存在。也许有人想知道这些例子的实际意义。非软件例子有助于增进模式语言的表达力和辅助模式的学习。

 

增加模式语言的表达能力

    Alexander  觉得真正的模式要融入一种通用的语言以便所有人都能够分享[2]。在软件设计的人群中，模式被认为是在同事之间一种约定俗成的开发方式[4，17]。模式提供了一种比模块、过程和对象更高层次的概念[10]。

    一种语言中至关重要的因素是同语言形象所对应的心灵影像。在一种语言中，仅当一个人能够领会一个符号的含义，能够在心里描绘出这种含义时，这个符号的外形才是有意义的[7]。Alexander没有忽视模式语言的这种重要特征，他规定：一种语言只有在它所产生的建筑类型能够被具体地看到之后，这种语言才是完全形态化的[1]。在软件设计中，Richle 和 Züllighoven认识到具体的例子在指导我们对应用领域的理解的重要性[12]。

   如果软件设计模式成为程序员中通用的语言，其基础则是统一的含义。如果设计决定下达了，但是没有被理解，则设计师被迫通过假设来完成工作[19]。平凡的例子更便于理解，其原因在于人们必须在记忆中找到相关联的内容才能够理解[20]。在广泛使用模式的AGComm  nicationSystems公司的项目中，常常使用非软件例子来解释模式之间的关系。这个例子有助于在设计师间提供统一的理解。通过在设计过程的先期建立统一的理解，使得在整个项目生命周期中，设计师间的沟通更加容易。

 

非软件例子作为学习模式的助手

 

   在新概念出现时，学生需要例子。这可以在AGComm nicationSystems 公司的模式推

 

行过程的总结中见到，同时这也是被其他人总结出来的[12]。在学习新东西时，学生很

 

自然地会使用学过的知识来帮助新概念的理解[6]。由于这个原因，许多例子应当在学

 

生第一次接触软件设计模式时提出[12]。某些例子应该在学生学习了一段时间以后提

 

出，而不是等他们成为专家以后。提供相似的例子并不增加需要学习的新内容。这

 

时，选取学生课外的例子可以避免学习素材短缺的情况。既然模式最终要停留在人的

 

头脑中[11]，因此可以使用大多数人熟悉的例子和 来自于记忆中的训练材料。

 

结论

   在非软件例子中软件设计模式的体现表明了模式不是局限于特定领域的。软件设计师可以从这些日常事物的模式举例中受益，哪怕这些例子并不是以程序设计语言表达的。这篇文章尽可能举一些大部分人所熟悉的例子（尽管某些倾向于北美文化）。通过对共同的经历的描述，这些例子有助于对特定的设计模式的理解，并且能够帮助对设计模式的学习。

  ※   感谢

本文作者非常感谢 Dalmatian Gro  p 的 Brandon Goldfedder，AG Comm  nication Systems 的 Linda Rising，H  mans

  and Technology 的 Alistair Cockb  rn 和伊利诺思大学的 Ralph Johnson 对本文提出的有益

 

建议。

※  参考书目

 

1.  Alexander, C. The Timeless Way of Building. O xford U niversity Press, 1979.

 

  2.  Alexander, C., et al. A Pattern Language. O xford U niversity Press, 1977.

 

3.  Anthony, D. "Patterns for Classroom Education", in Pattern Languages of Program Design II,

 

Addison-Wesley,1996.

 

4.  Berczuk, S. "Finding solutions through pattern languages", Computer, Vol. 27, No. 12.

December, 1994.

 

5.  Booch, G. "Object Oriented Design" in Tutorial on Software Design Techniques, pp. 420-

437, IEEE Computer Society, 1984.

 

6.  Carroll,  J.  "The  Nurnberg  funnel:  Designing  minimalist  instruction  for  practical 

 

computer  skill",  MIT  Press,1990.

 

7.  Chierchia, G. and McConnel-Ginnet, S. Meaning and Grammar: An Introduction to

Semantics. MIT Press, 1990.

 

  8.  Chilton, Chilton's Auto Repair Manual, Chilton Book Company, 1985.

 

9.  Coplien,  J.  "Broadening  beyond  objects  to  patterns  and  to  other  paradigms",  Position  statement  for  the  ACM Workshop on Strategic Directions in Computing Research, MIT, June 14-15, 1996.

(声明：本文Michael  Duell著，翻译者为Wu，出自<<非程序员>>，转载请注明此信息)