前言（一）

    如果你是一位软件开发人员，可能会有太多的事情要做，而你也许不知道如何将它们做全了。可能你对模式有所耳闻，因为在各种各样的消息源(比如计算机期刊和华尔街日报)中提及过模式。你可能也会认为模式能帮助你快速找到问题的答案。不过，如果你在寻找特定问题的快速解决方案，本书中的很多内容并不适合你。但如果你是在寻找一．问题的经过证明的解决方案，请继续阅读。

    编写计算机软件与许多其他学科不同。软件设计师创建抽象的结构，甚至在用户界面中也只能看到他们的一小部分工作。硬件设计师能触摸到他们的创造物，但是软件设计师无法触摸或看到他们所创建的成果，他们只能看到他们的创造物是如何运行的。你可以观察罗马高架渠的拱，并弄明白如何建造一个拱。但是不能观察计算机系统，并弄明白它是如何工作的。眼睛看不到很多错综复杂的情况。本书所介绍的模式是一些作者的成果，这些作者注意到了软件系统内部的规律性和重复出现的结构，他们会解释这些规律和结构，以帮助你避免犯错误。

    本书中的模式是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的程序主席。

    前言(二)

    Ralph Johnson和Ward Cunningham以"创立PLoP用于创建新文学"开始本系列的第一本书，这已经是6年前的事情了。目前，若干有关模式的书籍在计算机文学的核心体系中占据了应有的地位。模式已经改变了我们构建软件的思考方式以及我们的工作方式。建立项目团队时，我们遵循组织模式；分析领域时，我们应用分析模式组。我们中的很多人进行设计时，如果桌上没有著名的Gang of Four这本书，会感到心里空荡荡的。从OOPSLA上的研讨会开始，模式在不同的时间影响了软件产业以及计算机科学。

    那么什么因素造就了一种好的和我们不断寻找的模式呢?Jim Doble和GerardMeszaros在本系列前面的卷[Doble+1998]中对好的模式和模式语言的元素做了精彩的描述。而该书描述的是现象而不是起因，它描述了艺术家所要的技巧而不是艺术本身。读者经常谈到他们阅读一种好的模式时所得到的"温暖模糊的感觉"，或者谈到模式是如何与他们自己的经历产生"共鸣"的。许多计算机专业人士已经忘了倾听这些感觉，但是模式作者(和读者)正在学会接受它们。

    有3种元素有助于造就一个优秀的模式作者：经验、努力工作和态度。一种好的模式讨论了带来解决方案的所有强制条件和伴随它的所有陷阱和不足。它展示了作者和所有那些协助编写模式的人的经验，还展示了投入于创建模式的无数心血--文字、结构和流程。但最重要的是，它展示了吸引读者的愿望。好的模式写出来是为了读的，其整个结构的创立是用于引导读者通读文章，给他们这种模糊感觉以及这种与文献和作者的共鸣。它的目的是在引导读者更深入地理解问题和其解决方案的同时吸引他们。

    以人为本的态度是一种好模式的灵魂。它是模式团体的最深厚基础。在过去，模式的发展好比是一个宗教派别(尽管这有所争议)，二者都是基于价值体系且拥有哲学基础。模式提倡软件中的人性。也许这可以解释对模式文学的广泛兴趣和痴迷，因为与软件系统开发和使用相关的人士逐渐认识到，构建软件是一种极其人性化的活动。

    本卷中所有的模式都在PLoP大会上改进过。PLoP以及后来的EuroPLoP和ChiliPLoP创立用于培育模式和模式作者，鼓励作者写下他们下意识应用的模式并鼓励他们为Johnson和Cunningham的"新文学"做出贡献。我们相信，PLoP是一种与众不同的会议，不同之处在于我们关注软件开发的人的活动中的人。会议做了巨大努力来营造一种舒适和欢迎的氛围。它是仅有的带有小憩时间的会议。EuroPLoP限制与会人数，并不是因为它是排外的，而是为了确保小规模带来的亲密感和凝聚力。所有的PLoP会议都提供了许多社交活动和服务(从协作游戏到为那些不希望家人因自己的职业而受影响的人照顾孩子)，这些活动和服务有助于建立一个圈子，高度集中而富有效率的工作氛围也由此产生。

    作者研讨会是工作的重心，你在本书中所发现的所有模式都至少经历过一场研讨会。研讨会提供了一种支持和安全的环境，在其中作者能从同辈的其他与会作者那儿得到反馈。许多第一次参加PLoP会议的人认为他们到这里是来讲解他们的文章的，但是结果发现自己只是不被允许发言的人。你必须学会倾听你的读者，而不是希望他们能倾听你。也许这就是使得模式如此成功的原因。模式是由在自身领域中有专业经验的普通人写出来的，这些人想要提高他们的作品质量，也想帮助其他人提高作品质量。    

    Jens Coldewey

    Paul Dyson

    Jens Coldewey是德国慕尼黑的独立顾问，也是EuroPLoP'99的程序主席。

    Paul Dyson是Big Blue Steel Tiger有限公司的经济技术部门的主任，也是EuroPLoP'99的程序主席。