设计模式:可复用面向对象软件的基础(典藏版)(设计良好.表达清楚的软件设计模式)

本书结合设计实例从面向对象的设计中精选出23个设计模式, 总结了面向对象设计中*有价值的经验, 并且用简洁可复用的形式表达出来。本书分类描述了一组设计良好、 表达清楚的软件设计模式, 这些模式在实用环境下特别有用。 本书适合大学计算机专业的学生、研究生及相关人员参考。

埃里克·伽玛（Erich Gamma） 在瑞士苏黎世大学获得计算机科学博士学位。他与Kent Beck合作开发了单元测试框架JUnit，并领导了Eclipse Java Development Tools项目。他还曾是IBM Rational Jazz项目的主要成员。2011年，Gamma以杰出工程师（Distinguished Engineer）的身份加入微软Visual Studio团队，领导微软位于瑞士苏黎世的实验室。理查德·赫尔姆（Richard Helm） 在澳大利亚墨尔本大学获得计算机科学博士学位，曾在IBM T. J. Watson担任研究员，并在澳大利亚开创了IBM面向对象技术研究分部。拉尔夫·约翰逊（Ralph Johnson） 在美国康奈尔大学获得计算机科学博士学位，伊利诺伊大学教授，在模式、重构等领域均有很高造诣。约翰·威利斯迪斯（John Vlissides） 在美国斯坦福大学获得计算机科学博士学位，是IBM T. J. Watson研究中心的研究员。

出版者的话赞誉序言前言读者指南章引言┊11.1  什么是设计模式┊31.2  Smalltalk MVC中的设计模式┊41.3  描述设计模式┊61.4  设计模式的编目┊71.5  组织编目┊81.6  设计模式怎样解决设计问题┊101.6.1  寻找合适的对象┊101.6.2  决定对象的粒度┊111.6.3  指定对象接口┊111.6.4  描述对象的实现┊121.6.5  运用复用机制┊151.6.6  关联运行时和编译时的结构┊181.6.7  设计应支持变化┊191.7  怎样选择设计模式┊221.8  怎样使用设计模式┊24第2章实例研究：设计一个文档编辑器┊252.1  设计问题┊272.2  文档结构┊272.2.1  递归组合┊282.2.2  图元┊292.2.3  组合模式┊312.3  格式化┊312.3.1  封装格式化算法┊312.3.2  Compositor和Composition┊322.3.3  策略模式┊332.4  修饰用户界面┊342.4.1  透明围栏┊342.4.2  Monoglyph┊352.4.3  Decorator模式┊362.5  支持多种视感标准┊372.5.1  对象创建的抽象┊372.5.2  工厂类和产品类┊382.5.3  Abstract Factory 模式┊402.6  支持多种窗口系统┊402.6.1  是否可以使用Abstract Factory模式┊402.6.2  封装实现依赖关系┊412.6.3  Window和WindowImp┊432.6.4  Bridge模式┊462.7  用户操作┊462.7.1  封装一个请求┊472.7.2  Command类及其子类┊472.7.3  撤销和重做┊482.7.4  命令历史记录┊492.7.5  Command模式┊502.8  拼写检查和断字处理┊502.8.1  访问分散的信息┊512.8.2  封装访问和遍历┊512.8.3  Iterator类及其子类┊522.8.4  Iterator模式┊552.8.5  遍历和遍历过程中的动作┊552.8.6  封装分析┊562.8.7  Visitor类及其子类┊592.8.8  Visitor模式┊602.9  小结┊60第3章创建型模式┊623.1  Abstract Factory（抽象工厂）—对象创建型模式┊663.2  Builder（生成器）—对象创建型模式┊743.3  Factory Method（工厂方法）—对象创建型模式┊813.4  Prototype（原型）—对象创建型模式┊893.5  Singleton（单件）—对象创建型模式┊963.6  创建型模式的讨论┊102第4章结构型模式┊1044.1  Adapter（适配器）—类对象结构型模式┊1064.2  Bridge（桥接）—对象结构型模式┊1154.3  Composite（组合）—对象结构型模式┊1234.4  Decorator（装饰）—对象结构型模式┊1324.5  Facade（外观）—对象结构型模式┊┊1394.6  Flyweight（享元）—对象结构型模式┊1464.7  Proxy（代理）—对象结构型模式┊1554.8  结构型模式的讨论 ┊1644.8.1  Adapter与Bridge┊1644.8.2  Composite、Decorator与Proxy┊164第5章行为型模式┊1665.1  Chain of Responsibility（职责链）—对象行为型模式┊1675.2  Command（命令）—对象行为型模式┊1755.3  Interpreter（解释器）—类行为型模式┊1835.4  Iterator（迭代器）—对象行为型模式┊1935.5   Mediator（中介者）—对象行为型模式┊2055.6  Memento（备忘录）—对象行为型模式┊2125.7  Observer（观察者）—对象行为型模式┊2195.8  State（状态）—对象行为型模式┊2275.9  Strategy（策略）—对象行为型模式┊2345.10  Template Method（模板方法）— 类行为型模式┊2425.11  Visitor（访问者）—对象行为型 模式┊2465.12  行为型模式的讨论┊2565.12.1  封装变化┊2565.12.2  对象作为参数┊2575.12.3  通信应该被封装还是被分布┊2575.12.4  对发送者和接收者解耦┊2585.12.5  总结┊260第6章结论┊2616.1  设计模式将带来什么┊2626.1.1  一套通用的设计词汇┊2626.1.2  书写文档和学习的辅助手段┊2636.1.3  现有方法的一种补充┊2636.1.4  重构的目标┊2646.2  本书简史┊2656.3  模式界┊2666.3.1  Alexander的模式语言┊2666.3.2  软件中的模式┊2676.4  邀请参与┊2676.5  临别感想┊268附录A词汇表┊269附录B图示符号指南┊273附录 C基本类┊277参考文献┊284

    章引    言设计面向对象软件比较困难，而设计可复用的面向对象软件就更加困难。你必须找到相关的对象，以适当的粒度将它们归类，再定义类的接口和继承层次，建立对象之间的基本关系。你的设计应该对手头的问题有针对性，同时对将来的问题和需求也要有足够的通用性。你也希望避免重复设计或尽可能少做重复设计。有经验的面向对象设计者会告诉你，要一下子就得到复用性和灵活性好的设计，即使不是不可能的至少也是很好困难的。一个设计在很终完成之前经常要被复用好几次，而且每一次都有所修改。有经验的面向对象设计者的确能做出良好的设计，而新手则面对众多选择无从下手，总是求助于以前使用过的非面向对象技术。新手需要花费较长时间领会良好的面向对象设计是怎么回事。有经验的设计者显然知道一些新手所不知道的东西，这又是什么呢？内行的设计者知道：不是解决任何问题都要从头做起。他们更愿意复用以前使用过的解决方案。当找到一个好的解决方案时，他们会一遍又一遍地使用。这些经验是他们成为内行的部分原因。因此，你会在许多面向对象系统中看到类和相互通信的对象（communicating object）的重复模式。这些模式解决特定的设计问题，使面向对象设计更灵活、优雅，很终复用性更好。它们帮助设计者将新的设计建立在以往工作的基础上，复用以往成功的设计方案。一个熟悉这些模式的设计者不需要再去发现它们，而能够立即将它们应用于设计问题中。以下类比可以帮助说明这一点。小说家和剧本作家很少从头开始设计剧情。他们总是沿袭一些业已存在的模式，像“悲剧性英雄”模式（《麦克白》《哈姆雷特》等）或“浪漫小说”模式（存在着无数浪漫小说）。同样，面向对象设计者也沿袭一些模式，像“用对象表示状态”和“修饰对象以便你能容易地添加/删除属性”等。一旦懂得了模式，许多设计决策自然而然就产生了。我们都知道设计经验的重要价值。你曾经多少次有过这种感觉—你已经解决过一个问题但就是不能确切地知道是在什么地方或怎么解决的？如果能记起以前问题的细节和怎么解决它的，你就可以复用以前的经验而不需要重新解决它。然而，我们并没有很好记录下可供他人使用的软件设计经验。这本书的目的就是将面向对象软件的设计经验作为设计模式记录下来。每一个设计模式系统地命名、解释和评价了面向对象系统中一个重要的和重复出现的设计。我们的目标是将设计经验以人们能够有效利用的形式记录下来。鉴于此，我们编写了一些很重要的设计模式，并以编目分类的形式将它们展现出来。设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。设计模式帮助你做出有利于系统复用的选择，避免设计损害系统复用性。通过提供一个显式类和对象作用关系以及它们之间潜在联系的说明规范，设计模式甚至能够提高已有系统的文档管理和系统维护的有效性。简而言之，设计模式可以帮助设计者更快、更好地完成系统设计。本书中涉及的设计模式并不描述新的或未经证实的设计，我们只收录那些在不同系统中多次使用过的成功设计。这些设计的绝大部分以往并无文档记录，它们或是来源于面向对象设计者圈子里的非正式交流，或是来源于某些成功的面向对象系统的某些部分，但对设计新手来说，这些东西是很难学得到的。尽管这些设计不包含新的思路，但我们用一种新的、便于理解的方式将其展现给读者，即具有统一格式的、已分类编目的若干组设计模式。尽管本书涉及较多的内容，但书中讨论的设计模式仅仅包含了一个设计行家所知道的部分。书中没有讨论与并发、分布式或实时程序设计有关的模式，也没有收录面向特定应用领域的模式。本书并不准备告诉你怎样构造用户界面、怎样写设备驱动程序或怎样使用面向对象数据库，这些方面都有自己的模式，将这些模式分类编目也是件很有意义的事。1.1  什么是设计模式Christopher Alexander说过：“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”[AIS+77，0页]。尽管Alexander所指的是城市和建筑模式，但他的思想同样适用于面向对象设计模式，只是在面向对象的解决方案里，我们用对象和接口代替了墙壁和门窗。两类模式的核心都在于提供了相关问题的解决方案。一般而言，一个模式有四个基本要素：模式名（pattern name）  一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。问题（problem）  描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果。它可能描述了特定的设计问题（如怎样用对象表示算法等），也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。解决方案（solution）  描述了设计的组成成分、它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。效果（consequence）  描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。出发点的不同会产生对什么是模式和什么不是模式的理解不同。一个人的模式对另一个人来说可能只是基本构造部件。本书中我们将在一定的抽象层次上讨论模式。本书并不描述链表和hash表那样的设计，尽管它们可以用类来封装，也可复用；也不包括那些复杂的、特定领域内的对整个应用或子系统的设计。本书中的设计模式是对用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。设计模式命名、抽象和确定了一个通用设计结构的主要方面，这些设计结构能被用来构造可复用的面向对象设计。设计模式确定了所包含的类和实例，它们的角色、协作方式以及职责分配。每一个设计模式都集中于一个特定的面向对象设计问题或设计要点，描述了什么时候使用它，在另一些设计约束条件下是否还能使用，以及使用的效果和如何取舍。既然我们很终要实现设计，设计模式还提供了C++和Smalltalk示例代码来阐明其实现。虽然设计模式描述的是面向对象设计，但它们都基于实际的解决方案，这些方案的实现语言是Smalltalk 和C++等主流面向对象编程语言，而不是过程式语言（Pascal、C、Ada）或更具动态特性的面向对象语言（CLOS、Dylan、Self）。我们从实用角度出发选择了Smalltalk 和C++，因为在这些语言的使用上我们积累了许多经验，况且它们也变得越来越流行。程序设计语言的选择很好重要，它将影响人们理解问题的出发点。我们的设计模式采用了Smalltalk 和C++的语言特性，这个选择实际上决定了哪些机制可以方便地实现，而哪些则不能。若我们采用过程式语言，可能就要包括诸如“继承”“封装”和“多态”的设计模式。相应地，一些特殊的面向对象语言可以直接支持我们的某些模式，例如：CLOS支持多方法（multi-method）概念，这就减少了Visitor模式的必要性。事实上，Smalltalk和C++已有足够的差别来说明对某些模式一种语言比另一种语言表述起来更容易一些（参见5.4节Iterator 模式）。1.2  Smalltalk MVC中的设计模式在Smalltalk-80中，类的模型/视图/控制器（Model/View/Controller）三元组（MVC）被用来构建用户界面。透过MVC 来看设计模式将帮助我们理解“模式”这一术语的含义。MVC包括三类对象。模型（Model）是应用对象，视图（View）是它在屏幕上的表示，控制器（Controller）定义用户界面对用户输入的响应方式。不使用MVC，用户界面设计往往将这些对象混在一起，而MVC则将它们分离以提高灵活性和复用性。MVC通过建立一个“订购/通知”协议来分离视图和模型。视图必须保证它的显示正确地反映了模型的状态。一旦模型的数据发生变化，模型将通知有关的视图，每个视图相应地得到刷新自己的机会。这种方法可以让你为一个模型提供不同的多个视图表现形式，也能够为一个模型创建新的视图而无须重写模型。下图显示了一个模型和三个视图（为了简单起见我们省略了控制器）。模型包含一些数据值，视图通过电子表格、柱状图、饼图等不同的方式来显示这些数据。当模型的数据发生变化时，模型就通知它的视图，而视图将与模型通信以获取这些数据值。表面上看，这个例子反映了将视图和模型分离的设计，然而这个设计还可用于解决更一般的问题：将对象分离，使得一个对象的改变能够影响另一些对象，而这个对象并不需要知道那些被影响的对象的细节。这个更一般的设计被描述成Observer(5.7)模式。MVC的另一个特征是视图可以嵌套。例如，按钮控制面板可以用一个嵌套了按钮的复杂视图来实现。对象查看器的用户界面可由嵌套的视图构成，这些视图又可复用于调试器。MVC用View类的子类—CompositeView类来支持嵌套视图。CompositeView类的对象行为类似于View类的对象行为，一个组合视图可用于任何视图可用的地方，但是它包含并管理嵌套视图。上例反映了可以将组合视图与其构件平等对待的设计，同样，该设计也适用于更一般的问题：将一些对象划为一组，并将该组对象当作一个对象来使用。这个设计被描述为Composite(4.3)模式，该模式允许你创建一个类层次结构，一些子类定义了原子对象（如Button）而其他类定义了组合对象（CompositeView），这些组合对象是由原子对象组合而成的更复杂的对象。MVC允许你在不改变视图外观的情况下改变视图对用户输入的响应方式。例如，你可能希望改变视图对键盘的响应方式，或希望使用弹出菜单而不是原来的命令键方式。MVC将响应机制封装在Controller对象中。存在着一个Controller的类层次结构，使得可以方便地对原有Controller做适当改变而创建新的Controller。View使用Controller子类的实例来实现一个特定的响应策略。要实现不同的响应策略只要用不同种类的Controller实例替换即可。甚至可以在运行时通过改变View的Controller来改变View对用户输入的响应方式。例如，一个View可以被止接收任何输入，只需给它一个忽略输入事件的Controller。View-Controller关系是Strategy(5.9)模式的一个例子。一个策略是一个表述算法的对象。当你想静态或动态地替换一个算法，或你有很多不同的算法，或算法中包含你想封装的复杂数据结构时，策略模式是很好有用的。MVC还使用了其他的设计模式，如：用来指定视图默认控制器的Factory Method(3.3)和用来增加视图滚动的Decorator(4.4)。但是MVC的主要关系还是由Observer、Composite和Strategy三个设计模式给出的。1.3  描述设计模式怎样描述设计模式呢？图形符号虽然很重要也很有用，但还远远不够，它们只是将设计过程的结果简单记录为类和对象之间的关系。为了达到设计复用，我们必须同时记录设计产生的决定过程、选择过程和权衡过程。具体的例子也是很重要的，它们让你看到实际的设计。我们将用统一的格式描述设计模式，每一个模式根据以下模板被分成若干部分。模板具有统一的信息描述结构，有助于你更容易地学习、比较和使用设计模式。模式名和分类模式名简洁地描述了模式的本质。一个好的名字很好重要，因为它将成为你的设计词汇表中的一部分。模式的分类反映了我们将在1.5节介绍的方案。意图意图是回答下列问题的简单陈述：设计模式是做什么的？它的基本原理和意图是什么？它解决的是什么样的特定设计问题？别名模式的其他名称。动机用以说明一个设计问题以及如何用模式中的类、对象来解决该问题的特定情景。该情景会帮助你理解随后对模式更抽象的描述。适用性什么情况下可以使用该设计模式？该模式可用来改进哪些不良设计？你怎样识别这些情况？结构采用基于对象建模技术（OMT）[RBP+91]的表示法对模式中的类进行图形描述。我们也使用了交互图[JCJO92，BOO94]来说明对象之间的请求序列和协作关系。附录B详细描述了这些表示法。参与者指设计模式中的类和/或对象以及它们各自的职责。协作模式的参与者怎样协作以实现它们的职责。效果模式怎样支持它的目标？使用模式的效果和所需做的权衡是什么？系统结构的哪些方面可以独立改变？实现实现模式时需要知道的一些提示、技术要点及应避免的缺陷，以及是否存在某些特定于实现语言的问题。代码示例用来说明怎样用C++或Smalltalk实现该模式的代码片段。已知应用实际系统中发现的模式的例子。每个模式至少包括两个不同领域的实例。相关模式与这个模式紧密相关的模式有哪些？其间重要的不同之处是什么？这个模式应与哪些其他模式一起使用？附录提供的背景资料将帮助你理解模式以及关于模式的讨论。附录A给出了我们使用的术语列表。前面已经提到过的附录B则给出了各种表示法，我们也会在以后的讨论中简单介绍它们。很后，附录C给出了我们在例子中使用的各基本类的源代码。

本书并不是一本介绍面向对象技术或设计的书，目前已有不少好书介绍面向对象技术或设计。本书假设你至少已经比较熟悉一种面向对象编程语言，并且有一定的面向对象设计经验。当我们提及“类型”和“多态”，或“接口”继承与“实现”继承的关系时，你应该对这些概念了然于胸，而不是迫不及待地翻阅手头的字典。另外，这也不是一篇不错专题技术论文，而是一本关于设计模式的书，它描述了在面向对象软件设计过程中针对特定问题的简洁而优雅的解决方案。设计模式捕获了随时间进化与发展的问题的求解方法，因此它们并不是人们从一开始就采用的设计方案。它们反映了不为人知的重新设计和重新编码的成果，而这些都来自软件开发者为了设计出灵活、可复用的软件而长时间进行的艰苦努力。设计模式捕获了这些解决方案，并用简洁易用的方式表达出来。设计模式并不要求使用独特的语言特性，也不采用那些足以使你的朋友或老板大吃一惊的神奇的编程技巧。所有的模式均可以用标准的面向对象语言实现，这也许有时会比特殊的解法多费一些功夫，但是为了增加软件的灵活性和可复用性，多做些工作是值得的。一旦理解了设计模式并且有了一种“Aha！”（而不是“Huh？”）的应用经验和体验后，你将用一种非同寻常的方式思考面向对象设计。你将拥有一种深刻的洞察力，以帮助你设计出更加灵活的、模块化的、可复用的和易理解的软件—这也是你着迷于面向对象技术的原因，不是吗？当然还有一些提示和鼓励：次阅读此书时你可能不会完全理解它，但不必着急，我们在起初编写这本书时也没有完全理解它们！请记住，这不是一本读完一遍就可以束之高阁的书。我们希望你在软件设计过程中反复参阅此书，以获取设计灵感。我们并不认为这组设计模式是完整的和一成不变的，它只是我们目前对设计的思考的记录。因此我们欢迎广大读者的批评与指正，无论从书中采用的实例、参考，还是我们遗漏的已知应用，或应该包含的设计模式等方面。你可以通过Addison-Wesley写信给我们，或发送电子邮件到design-patterns@cs.uiuc.edu。你还可以发送邮件“send design pattern source”到design-patterns-source@cs.uiuc.edu获取书中的示例代码部分的源代码。另外我们有一个专门的网页报道最新的消息与更新：http://st-www.cs.uiuc.edu/users/patterns/DPBook/DPBook.htmlE. G. 于加州Mountain ViewR. H. 于蒙特利尔R. J. 于伊利诺伊UrbanaJ. V. 于纽约 Hawthorne1994年8月所有结构良好的面向对象软件体系结构中都包含了许多模式。实际上，当我评估一个面向对象系统的质量时，所使用的方法之一就是要判断系统的设计者是否强调了对象之间的公共协同关系。在系统开发阶段强调这种机制的优势在于，它能使所生成的系统体系结构更加精巧、简洁和易于理解，其程度远远超过了未使用模式的体系结构。模式在构造复杂系统时的重要性早已在其他领域中得到认可。特别是，Christopher Alexander和他的同事们可能最先将模式语言（pattern language）应用于城市建筑领域，他的思想和其他人的贡献已经根植于面向对象软件界。简而言之，软件领域中的设计模式为开发人员提供了一种使用专家设计经验的有效途径。在本书中，Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides介绍了设计模式的原理，并且对这些设计模式进行了分类描述。因此，该书做出了两个重要的贡献：首先，它展示了模式在构建复杂系统过程中所处的角色；其次，它为如何引用一组精心设计的模式提供了一个实用方法，以帮助实际开发者针对特定应用问题使用适当的模式进行设计。我曾荣幸地与本书的部分作者一同进行体系结构设计工作，从他们身上我学到了许多东西，相信阅读本书也能让你受益匪浅。Rational 软件公司首席科学家 Grady Booch