程序设计的模式语言·卷4

　　 作为提高软件工程、系统设计与开发的效率和质量的一种极期有效的方法，设计模式步入了商业软件开发的主流。模式收录了许多优秀的软件设计的实践经验，并把这些经验提供给所有软件工程师。
　　 本书是为专业软件开发者记载模式的系列书籍的第4卷，代表了模式领域最先进的实践。本书中的29章都发表于最近的plop会议上，且由与会的权威专家对其做了深入的研究和改进。这些代表着plop会议精华的模式提供了用于解决各种领域中现实问题的有效的、经过测试的和通用的软件设计解决方案。
　　 本书涉猎广泛，涉及面向对象基础结构、编程策略、时间模式、安全性、面向域模式、人机交互、评审和软件管理领域的模式。在其中，你会找到：
　　 ·角色对象
　　 ·主动反应
　　 ·c++语言风格
　　 ·安全性结构模式
　　 ·报告
　　 ·组合多媒体人工制品
　　 ·用户交互
　　 随着模式由研究领域逐步发展到应用实际软件开发中，越来越多的开发者认识到可重用的设计模式（如包含在本卷中的这些模式）能帮助他们更快更经济地开发应用程序。

第1部分 基本面向对象模式
第1章 abstract class（抽象类）
第2章 role object（角色对象）
第3章 essence（本质）
第4章 object recursion（对象递归）
第5章 prototype-based object system（基于原型的对象系统）
第6章 basic relationship（基本关系）模式
第2部分 面向对象基础结构（object-oriened infrastructure）模式
第7章 abstract session（抽象会话）：一种对象结构模式
第8章 object synchronizer（对象同步器）
第9章 proactor（主动反应）
第3部分 编程策略
第10章 c++语言模式
第11章 smalltalk体系结构模式
第12章 存储器维护协会的high-level and process（高级和处理）模式：管理有限的存储器模式
第4部分 时间
第13章 temporal（时间模式）模式
第14章 history（历史）模式集合
第5部分 安全性
第15章 支持应用程序安全性的体系结构模式

　　前言（一）
　　 如果你是一位软件开发人员，可能会有太多的事情要做，而你也许不知道如何将它们做全了。可能你对模式有所耳闻，因为在各种各样的消息源(比如计算机期刊和华尔街日报)中提及过模式。你可能也会认为模式能帮助你快速找到问题的答案。不过，如果你在寻找特定问题的快速解决方案，本书中的很多内容并不适合你。但如果你是在寻找一．问题的经过证明的解决方案，请继续阅读。
　　 编写计算机软件与许多其他学科不同。软件设计师创建抽象的结构，甚至在用户界面中也只能看到他们的一小部分工作。硬件设计师能触摸到他们的创造物，但是软件设计师无法触摸或看到他们所创建的成果，他们只能看到他们的创造物是如何运行的。你可以观察罗马高架渠的拱，并弄明白如何建造一个拱。但是不能观察计算机系统，并弄明白它是如何工作的。眼睛看不到很多错综复杂的情况。本书所介绍的模式是一些作者的成果，这些作者注意到了软件系统内部的规律性和重复出现的结构，他们会解释这些规律和结构，以帮助你避免犯错误。
　　 本书中的模式是PLoP(Pattern Languages of Programming，程序设计的模式语言)会议的成果。与会者说，PLoP会议是他们所参加过的最好的技术性会议之一，原因之一是PLoP把实践者聚集在一起讨论问题的解决方案。它们也给模式作者提供了一个支持平台来分享他们最新的创造性工作，PLoP就是关于经验分享的。
　　 PLoP的主要目标是改进模式文学和模式写作的质量。在PLoP'97上，我们营造了一种支持作者创造性的氛围。除了传统的作者研讨会(Writers'Workshops)之外，也举行写作研讨会，给作者培养他们创造性的机会。在PLoP'98上，我们没有按照传统的标准给模式提交稿件归类。我们想要看看研讨会参与者是否能发现他们模式之间的联系，并带着构建新联系的想法离开大会。有一些人已经这样做了，并且出现了许多正在进行中的受本次大会启发产生的协作(比如组件设计和配置管理模式)。
　　 模式作者从Christopher Alexander身上得到灵感。Christopher Alexander是一位建筑师，他试图从其他事务中捕获使建筑漂亮的"无名的性质"(Quality Without a Name)。软件开发人员从Christopher Alexander的工作中得到的重要成果不是与建筑相关的事务，而是通过美化来改进质量的方法的实践价值。Donald Knuth在其1974年图灵奖(Turning Award)演说中说道：
　　 "我感到，当我们为程序做准备时，经历就好比是写诗或编曲；当我们阅读他人的程序时，我们能够承认其中一些程序是真正的艺术品。有些程序很优雅，有些很精美，有些闪烁着智慧的灵光。我认为，编写出宏伟的、高贵的、真正华丽的程序是可能的。"
　　 在你认为这个目标过于理想化或者抽象之前，请记住，模式是关于经过证明的解决方案的，而不是关于新鲜和独特的解决方案的。在Alexander的自传Christopher Alexander：the Search for a New Paradigm in Architecture中，Stephen Grabow描写了Alexander对简单时髦建筑的厌恶。Alexander的模式描述"显而易见的事物"，这由于我们沉迷于时髦和潮流中而被我们中的大多数人所忽略了。尽管实际情况是新的和大胆的建筑物通常不适合于居住和工作，但这些建筑物常常获得奖项。在软件行业也是如此。较之更加陈旧的经过证明的想法，某些软件开发文化更青睐新鲜的未经证明的想法，其重点常放在发明上。但是优美的技巧并不总是产生更好的程序。除非你的问题与众不同(从正确的尺度来看，与众不同的问题是很罕见的)，不然新颖并不总是好的。你常常会发现，你所碰到的优雅的、效率高的解决方案实际上之前已经被许多其他方案使用过了，尽管可能是在孤立的状态下被使用。模式是这样一种尝试：它试图捕获那些经过长时间观察的显而易见的解决方案。
　　 从某种意义上说，软件的发展就好比是传统医学。不幸的是，今天的计算机编程是许多许多代之前的医学：个人试图解决问题，发现不想要的副作用，做个人记录以便后代能从他们的经验中获益；模式试图将记录传播到更广泛的群体中，而不仅仅是传给合作者。它们是关于事情的故事--我们所看到的从不久的以前一直到现在起作用的事情。它们是记录，我们可以把记录传给后面的设计师以便他们能避免同样的一些错误。PLoP上的研讨会支持分享和确认经验的过程。作者提交他们推荐作为通用解决方案的模式。研讨会和其他论坛的参与者添加他们的故事，要么确认要么否认这些方案是模式。模式作者在系统内部寻找创建结构的底层结构和过程，然后把他们的观察记录下来，以便其他人能分享他们的经验。由于本书中的论文所涉猎的过程的本质，你能确信，它们不是一些具有创造性的人的想法。本书和更加传统的学术作品的区别在于，在本书中没有任何东西是新的，它可能只是个别读者还没有发现的事物。
　　 模式封装了多年的程序开发、观察和经验。找到解决方案很简单，但要找到正确的解决方案，就需要理解问题和影响问题的强制条件。书中的内容会帮助你做出困难的决定。它以某种方式让你接触到一些经过证明的问题的解决方案，你能从那些初看上去差别不大的若干方法中找到你想要的方案。这些模式能帮助你，但是它们不会将方案交给你。在某种意义上，模式的价值和威力把被它们接受为有用事物的方式掩盖了。Design Patterns(《设计模式》)[Gamma+1995]被认为是一本有用的书，它描述了每个对象开发人员应该熟悉的思想。Design Patterns捕获了关键习语，后面紧跟关于它们的适用性的合理建议。这是一本每个开发人员都应拥有的书，不过，它只涉及了模式是关于什么的表面知识。
　　 从某种意义上说，模式是关于对美丽和优雅的追求。模式也是关于遵循其他成功系统，快速构建可靠系统的需要。通过提供给你机会学习其他人的经验，模式将你从重复的任务中解放出来，允许你集中精力于创新和发明。模式作者来自开发过程的各个方面，从管理人员和软件架构师到普通开发人员。每一个与软件系统和开发有关的人都有能力观察和记录那些运行良好的重复出现的主题。
　　 通常人们(特别是软件领域人士)喜欢归类。许多系统会比最初看到的有更多的共性。当浏览本书的目录寻找答案时，不要仅仅因为标题不符合你对问题的直接感觉，而把特定章节当作介绍性内容放弃。如果你是在用Smalltalk编程，尽管你可能不会马上用到Coplien的C++模式，但是如果你不得不设计很普通的I／O时，你会发现Hamer和Stymfal的第23章中的模式会很有用。本书中的章节按多种方式分类，你这里所看到的类别是各种可能性的最好折中。本书中的模式的作者共享他们的智慧和创造性，以帮助你从他们在各种各样系统中所看到的事物中获益。有些人写作的内容可用于帮助新手学会如何用正确的方法做事，或者至少是帮助他们尽可能减少错误。有些人通过收集跨领域的问题／解决方案空间的模式语言，来全面记载领域。我们有关模式的工作只是开了个头。《程序设计的模式语言》系列以及其他一些工作是捕获软件开发专家经验的尝试，组织这种专家经验以使其可用的工作正在进行中。也许作为读者的你能帮助找到这些模式作者、审稿人和编辑所没有发现的联系和应用。
　　 当连接到其他模式时，模式就显示出了它的威力。这是人们所称为"背景"的模式，即在一个"更高层次"上存在的模式。使用组织内部的特定工具、过程和语言，从体系结构构建软件系统。本书中的模式涵盖了所有这些方面，并且每件作品都独自成文。阅读时，注意模式与作者所关注的领域之外的模式可能的应用之间的联系。
　　 本书中的思想可能对你而言不全是新的。如果你阅读到其中某一章，会心地发出"我知道这个!"的感慨，那你就承认了作者的工作。如果你在本卷中没有发现任何新的内容，那你可能是一位专家。事实上，没有一个软件开发人员是无所不知的。本书和本系列中前面的书籍是构建经过证明的技术的文献体系过程的一部分，你可以使用这种体系，在其基础上构建你自己的工作和乐趣。
　　 我们希望你会发现本书是有用的、有乐趣的，甚至是有启发性的。
　　 Steve Berczuk
　　 BobHanmer
　　 Steve Berczuk是NetSuite Development Corporation公司的软件工程师，也是PLoP'98的程序主席。
　　 Bob Hanmer是Lucent Technologies的知名技术人士，也是PLoP'97的程序主席。
　　 前言(二)

　　 时间：1621年；地点：普利茅斯(Plymouth)，此处最后变为马萨诸塞州(Massachusetts)。1620年11月抵达普利茅斯的一群英格兰定居者要开始种植农作物了。不久以后，一位名叫Squanto的印第安人前来拜访。他显然是一位园艺爱好者，他提议给这些定居者教授种植技巧。首先是将鱼放入土里使土地肥沃，这种技巧加上其他一些新大陆(New World)的种植技巧带来了巨大的丰收。定居者顺利度过了随之而来的冬季，这在很大程度上要感谢Squanto和他明智的建议。
　　 毫无疑问，这是一个虚假的故事。但是现代园艺家肯定了Squanto关于鱼在农业中的作用的见解。实际上，你可在许多园艺商店买到鱼肥。我们的农业祖先可能不具有植物生理学的深厚知识，但是他们知道什么有用，而且还把经验一代一代传下来。
　　 一百多年以后，在半个地球远的地方，即现在的德国，一位多才多艺的大师展现了他的才华。传说Johann Sebastian Bach拜访普鲁士国王Frederick，寒暄过后，国王要Bach为他演奏。Bach在风琴旁坐下，即兴创作了一首5个乐章的赋格曲，自身也是作曲家的国王对Bach钦佩不已。
　　 Bach的作品是巴洛克音乐的经典。他把本领传给了后代--他的后代中的许多人也变成了重在的音乐家和作曲家。
　　 知识代代相传。语言就是生动的例子，经久不衰，从口传单词和概念演变而来，从一个人传给另一个人。这方面的一个例子是英语，其源头可追溯到许多语言，包括德语、希腊语和拉丁语。这里有一个问题；英语的多方面继承带来了一个显然会使人混乱的拼写规则的大杂烩。比如，在"physics"中，我们把字母ph拼作"f"音；而在"fish"和"fugue"中，则把"f"拼作"f"音。对于这种不规范性有其历史和语言学的原因，不过这些对我们没有造成影响。我们只是记住了，它是"fugue"而不是"phugue"。
　　 在软件中，我们没有数个世纪的历史可以依靠。我们没有从先辈那里学会农业，也不能追根溯源到中世纪Chaucer时代的英语。但我们存在的时间已足够我们学会一些事情了。其中最重要的一条就是：我们必须分享我们学到的。如果我们都把知识占为已有，像林鼠那样把其存储起来，那么我们所从事的领域肯定会停滞不前，我们注定要使同行和继任者重复我们犯过的错误。慢慢地，重新发明取代了创新。进步减慢了，领域变得愈加贫瘠。
　　 模式是知识的导管，可以用来获取和传送经过时间证明的实践。模式不仅仅是技巧或者着起来很随意的拼写规则，它们可以传递理解。它们不仅仅告诉你what和how，还告诉你why和when，这是它们的真正力量所在。
　　 我们能从模式那里合理地期望得到什么?也许、宙们会帮助其他人开发出比我们所开发的更好的软件；也许它们会允许人们把他们做的土作建立在我们所做工作的基础上。我们肯定希望模式能帮助其他人避免我们遇到过的陷阱。
　　 不过我们可以期望更多。计算机技术的广泛传播对社会施加了巨大的影响，从而必须负责任地运用它们。虽然模式不会强制你负责任地做事，但它们能减轻重新发明的痛苦，把你解放出来以考虑更高层次的目的。最终，模式使得每个人(软件用户和开发人员)的生活更加美好。
　　 无疑，目标有高有低。我们希望"程序设计的模式语言"系列的第4卷能实现这些目标。
　　致谢
　　 现在要对为本书作过贡献的人表示感谢。如果不是很多人一起努力，这么厚的图书是不会出现的。我们非常感谢他们的工作。我们特别感谢为本书提供必需稿件的作者，他们为我们解决了很多疑难问题。我们并不仅仅是指可以在本书中找到的作者，还包括那些其作品没有采纳的大约60％的提交者。极高质量的提交稿件尽管加大了我们工作的难度，但是它确保了本书的质量。
　　 我们聘用了大量的审稿人帮助筛选提交稿件。我们把我们的理智归功于他们：FrancisAnderson, Brad Appleton, Jorge Arjona, Owen Astrannen, Ken Auer, JeffBarcalow, Kent Beck,Mike Beedle, Steve Berczuk, Manish Bhatt, Rosana Braga, John Brant Kyle Brown, Jose Burgos,Frank Buschmann, Andy Carlson, Ian Chai, Alistair Cockburn, Jens Coldewey, James Coplien,Ward Cunningham, David Cymbala, Fonda Daniels, Dennis DeBruler, Michel DeChamplain,David Delano, Dwight Deugo, Paul Dyson, Philip Eskelin, Javier Galve, Julio Garcia, AlejandraGarrido, John Goodsen, Robert Hanmer, Kevlin Henney, Robert Hirschfeld, Ralph Johnson,Wolfgang Keller, Elizabeth Kendall, Norm Kerth, Charles Knutson, Frederick Koh, PhilippeLalanda, Manfred Lange, Doug Lea, Mary Lynn Manns, Klaus Marquardt, Paulo Masiero, SkipMcCormick, Regine Meunier, Oscar Nierstrasz, James Noble, Alan O'Callaghan, Don Olson,William Opdyke, Dorina Petriu, Irfan Pyarali, Andreas Rausch, Dirk Riehle, Linda Rising,Ant6nio Rito Silva, Don Roberts, Gustavo Rossi, Cecilia Rubira, Andreas ROping, DougSchmidt, Afl Schoenfeld, Dietmar Schiitz, Christa Schwanninger, Joe Seda, Peter Sommefiad,Michael Stal, Paul Taylor, Jenifer Tidwell, Dwayne Towell, David Ungar.我们特别感谢本系列丛书的主编John Vlissides。他给了我们鼓励和必要的鞭策。Neil要特别感谢他的两位合作编辑，和你们一起工作是一种快乐。
　　 最后，我们特别感谢支持我们一路走来的我们的家人、朋友和合作者。我们希望在你们读到这里时，我们将重新做回快乐的自己。
　　 Neil Harrison，丹佛，科罗拉多州
　　 Brian Foote，乌尔班纳，伊利诺伊州
　　 Hans Rohnert，慕尼黑，德国