图解设计模式——引言

大家好，我是结城浩。欢迎阅读《图解设计模式》。 想必大家在编写程序的时候，也曾遇到“咦，好像之前编写过类似的代码”这样的情况。随着开发经验的增加，大家都会在自己的脑海中积累起越来越多的“模式”，然后会将这些“模式”运用于下次开发中。 Eric Gamma、Richard Helm、Ralph Johnson、John Vlissides 等4 人将开发人员的上述“体会”和“内在积累”整理成了“设计模式”。这4 人被称为the Gang of Four，简称GoF。 GoF 为常用的23 种模式赋予了“名字”，并按照类型对它们进行了整理，编写成了一本书，这本书就是《设计模式：可复用面向对象软件的基础》（请参见附录E 中的 [GoF]）。 大家应当都知道，当多个模块组合在一起工作时，接口是非常重要的。其实，这条原则不仅仅适用于计算机，也适用于人。当多位开发人员一起工作的时候，“人”这个接口也非常重要，而这个接口的基础就是“语言”。特别是脱离具体代码、只讨论程序的大致结构时，语言和图示就显得尤其重要。比如，另外一位开发人员提出的改进方案与我的方案究竟是否相同？是不是大框架相同而细节不同呢？如果有无限的时间与耐力，这些问题都是可以通过反复讨论解答出来的。但是，如果借助设计模式的术语来表达想法，我们就可以更加轻松地比较两人的观点，进而使讨论进行得更加顺利。 设计模式为开发人员提供了有益且丰富的词汇，让开发人员可以更容易地理解对方所要表达的意思。 本书将对GoF 的23 种设计模式逐一进行讲解，让那些面向对象的初学者也可以很轻松地理解这些设计模式。本书并非仅仅给出枯燥的设计模式理论，还会用Java 语言编写实现了设计模式的示例程序，并让程序真正地运行起来。我们学习设计模式，并不是为了遥远的将来而打算，而是将它当作是一种有益的技巧，因为它可以帮助我们从全新的角度审视我们每天所编写的代码，从而帮助我们开发出更易于复用和扩展的软件。 本书的特点 ◆用Java 语言编写可实际运行的程序 我们会编写Java 程序代码来实现GoF 的23 种设计模式。为了方便大家通读这些代码，所有的代码都只有100 行左右，非常精简。而且，所有的代码中都没有“以下代码省略”的部分，且都经过笔者自己编译并运行过。 ◆模式名称的讲解 设计模式的名称原本不是汉语，而是英语。开发人员如果不精通英语，就无法由设计模式的名称直接联想到它的作用。因此，本书还会讲解各设计模式的名称是什么意思，以及怎样用汉语表达。这样一来，那些不擅长英语的开发人员也可以很轻松地掌握设计模式。 ◆模式之间的关联与练习题 设计模式不需要死记硬背。要想掌握模式，必须要多练习，比如试着在阅读程序时识别出模式，在编写程序时运用模式。因此，必须了解模式之间的关联，并练习运用模式解决具体问题。本书为大家设计了用于学习设计模式的练习题和答案。 ◆ Java 语言的相关信息 本书不仅会讲解设计模式，还会向读者展示一些信息以帮助大家深入理解Java。带有Java 符号的内容表示这部分是和Java 语言相关的信息。 ◆模式插图 如果只阅读文字讲解内容，很难掌握这些模式。在本书中，我们在每章的首页中都放了一张图片来直观地展示所要学习的模式，这样可以帮助大家更加轻松地掌握模式。 本书的读者 本书适合以下读者阅读。 ● 对面向对象开发感兴趣的人 ● 对设计模式感兴趣的人 （特别是阅读了GoF 的著作但是难以理解的人） ● 所有Java程序员 （特别是对抽象类和接口的理解不充分的人） 阅读本书需要掌握Java 语言的基本知识。具体而言，至少需要理解类和接口、字段和方法，并能够编译和运行Java 源代码。 虽然本书讲解的是设计模式，但必要时也会对Java 语言的功能进行补充说明，因此读者还可以在阅读本书的过程中加深对Java 的理解。特别是对于那些对抽象类和接口的目的理解不充分的读者来说，本书具有很大的参考价值。 此外，即使不了解Java 语言也没关系。如果了解C++ 语言，同样可以轻松理解本书中的内容。如果想从零开始学习Java 语言，建议读者在阅读本书前，先阅读笔者的拙作《Java 语言编程教程（修订版）》A（请参见附录E [Yuki03]）。 另外，建议学习完本书的读者再去学习一下《图解设计模式：多线程》B（请参见附录E[Yuki02]）。 本书的结构 本书结构如下所示，各章基本上与GoF 设计模式的章节相对应。但是笔者对设计模式的分类与GoF 不同，因此章节划分也不尽相同。关于GoF 对设计模式的分类，请参见附录C。 A　原书名为『改訂版　Java 言語プログラミングレッスン』，尚无中文版。——译者注 B　原书名为『Java 言語で学ぶデザインパターン入門　マルチスレッド編』，人民邮电出版社即将引进出版。——译者注 ● 在第1部分“适应设计模式”中，我们将学习一些比较容易理解的设计模式，并以此来适应设计模式的概念。 ● 在第1 章“Iterator 模式——一个一个遍历”中，我们将要学习从含有多个元素的集合中将各个元素逐一取出来的Iterator 模式。 ● 在第2 章“Adapter 模式——加个‘适配器’以便于复用”中，我们将要学习Adapter 模式，它可以用来连接具有不同接口（API）的类。 ● 在第2部分“交给子类”中，我们将学习与类的继承相关的设计模式。 ● 在第3 章“Template Method 模式——将具体处理交给子类”中，我们将要学习在父类中定义处理框架，在子类中进行具体处理的Template Method 模式。 ● 在第4 章“Factory Method 模式——将实例的生成交给子类”中，我们将要学习在父类中定义生成接口的处理框架，在子类中进行具体处理的Factory Method 模式。 ● 在第3部分“生成实例”中，我们将学习与生成实例相关的设计模式。 ● 在第5 章“Singleton 模式——只有一个实例”中，我们将要学习只允许生成一个实例的Singleton 模式。 ● 在第6 章“Prototype 模式——通过复制生成实例”中，我们将要学习复制原型接口并生成实例的Prototype 模式。 ● 在第7 章“Builder 模式——组装复杂的实例”中，我们将要学习通过各个阶段的处理以组装出复杂实例的Builder 模式。 ● 在第8 章“Abstract Factory模式——将关联零件组装成产品”中，我们将要学习像在工厂中将各个零件组装成产品那样生成实例的Abstract Factory 模式。 ● 在第4部分“分开考虑”中，我们将学习分开考虑易变得杂乱无章的处理的设计模式。 ● 在第9 章“Bridge 模式——将类的功能层次结构与实现层次结构分离”中，我们将要学习按照功能层次结构与实现层次结构把一个两种扩展（继承）混在一起的程序进行分离，并在它们之间搭建桥梁的Bridge 模式。 ● 在第10 章“Strategy 模式——整体地替换算法”中，我们将要学习Strategy 模式，它可以帮助我们整体地替换算法，使我们可以更加轻松地改善算法。 ● 在第5部分“一致性”中，我们将学习能够让两个看上去不同的对象的操作变得统一，以及在不改变处理方法的前提下增加功能的设计模式。另外，我们还要学习“委托”。 ● 在第11 章“Composite模式——容器与内容的一致性”中，我们将要学习让容器和内容具有一致性，从而构建递归结构的Composite 模式。 ● 在第12 章“Decorator 模式——装饰边框与被装饰物的一致性”中，我们将要学习让装饰边框与被装饰物具有一致性，并可以任意叠加装饰边框的Decorator 模式。 ● 在第6部分“访问数据结构”中，我们将学习能够漫步数据结构的设计模式。 ● 在第13 章“Visitor 模式——访问数据结构并处理数据”中，我们将要学习在访问数据结构的同时重复套用相同操作的Visitor 模式。 ● 在第14 章“Chain of Responsibility模式——推卸责任”中，我们将要学习可以处理连接在一起的多个对象中某个地方的Chain of Responsibility 模式。 ● 在第7部分“简单化”中，我们将学习可以让类关系简单的设计模式。 ● 在第15章“Facade模式——简单窗口”中，我们将要学习Facade模式，该模式并不是单独地控制那些错综复杂地关联在一起的多个类，而是通过配置一个窗口类来改善系统整体的可操作性。 ● 在第16 章“Mediator 模式——只有一个仲裁者”中，我们将要学习可以不与多个复杂的类打交道，而是准备一个窗口，然后通过与这个窗口打交道来简化程序的Mediator 模式。 ● 在第8部分“管理状态”中，我们将学习与状态相关的设计模式。 ● 在第17 章“Observer 模式——发送状态变化通知”中，我们将要学习将状态发生变化的类和发送状态变化通知的类分开实现的Observer 模式。 ● 在第18 章“Memento 模式——保存对象状态”中，我们将要学习可以保存对象现在的状态，并可以根据情况撤销操作，将对象恢复到以前状态的Memento 模式。 ● 在第19 章“State 模式——用类表示状态”中，我们将要学习用类来表现状态，以减少switch 语句的State 模式。 ● 在第9部分“避免浪费”中，我们将学习可以避免浪费、提高处理效率的设计模式。 ● 在第20 章“Flyweight 模式——共享对象，避免浪费”中，我们将要学习当多个地方有重复对象时，通过共享对象来避免浪费的Flyweight 模式。 ● 在第21 章“Proxy模式——只在必要时生成实例”中，我们将要学习除非必须“本人”处理，否则就只使用代理类来负责处理的Proxy 模式。 ● 在第10部分“用类来表现”中，我们将学习用类来表现特殊东西的设计模式。 ● 在第22 章“Command 模式——命令也是类”中，我们将要学习用类来表现请求和命令的Command 模式。 ● 在第23 章“Interpreter模式——语法规则也是类”中，我们将要学习用类来表现语法规则的Interpreter 模式。 本书中的示例代码 示例代码的获取方法 本书的示例代码可以从以下网址下载（点击“随书下载”）： http://www.ituring.com.cn/book/1811 详细信息请参见附录B。 从Main 类启动示例代码 在Java 中，只要类中定义了以下方法，就可以将该类作为程序的起点： public static void main(string[]) 但是在本书中，为了使读者能够更容易理解代码，各章的示例程序都使用Main 类作为程序的起点。 关于本书中术语的注意事项 接口和API 接口这个术语有多个意思。 一般而言，在提到“某个类的接口”时，多是指该类所持有的方法的集合。当想要对该类进行某些操作时，需要调用这些方法。 但是在Java 中，也将“使用关键字interface 声明的代码”称为接口。 这两个“接口”的意思有些相似，在使用时容易混乱，因此本书中采用以下方式加以区分。 ● 接口（API）：通常的意思（API是application programming interface的缩写） ● 接口：使用关键字interface声明的代码 模式、类和角色 在本书中，模式这个词表示设计模式的意思。例如，“GoF 一共在书中整理了23 种模式”指的就是“GoF 一共在书中整理了23 种设计模式”。另外，我们会将名为Memento 的设计模式简称为“Memento 模式”。 类是指Java 中的类，即以class 关键字定义的程序。例如，在书中会有“这段程序中定义的是Gamer 类”这种描述；而“Memento 类”则是指在程序上用class Memento { ... } 定义的代码。 角色是本书中特有的说法。它是指模式（设计模式）中出现的类、接口和实例在模式中所起的作用。例如，在书中会有“由Gamer 类扮演Originator 角色” 这种描述。当然，也存在角色的名字与类和接口的名字不一致的情况。 此处的内容很繁琐，但是当大家阅读本书时，就会理解笔者在这里想要表达的意思了。 致谢 首先需要向整理出设计模式的Eric Gamma、Richard Helm、Ralph Johnson、John Vlissides 这4人表示感谢。 然后，还要向阅读笔者拙作，包括图书、连载杂志和电子邮件杂志的读者们表示感谢。另外，还要向笔者Web 主页上的朋友们表示感谢。 笔者在编写本书的原稿、程序以及图示的过程中，也同时将它们公布在了互联网上，以供大家评审。在互联网上招募的评审人员不限年龄、国籍、性别、住址、职业，所有交流都是通过电子邮件和网络进行的。在此，笔者要向参与本书评审的朋友们表示感谢，特别是对给予了我宝贵意见、改进方案，向我反馈错误以及一直鼓励我的以下各位表示我最真挚的感谢（按五十音图顺序排列）：新真千惠、池田史子、石井胜、石田浩二、井芹义博、宇田川胜俊、川崎昌博、榊原知香子、砂生贵光、佐藤贵行、铃木健司、铃木信夫、竹井章、藤森知郎、前田恭男、前原正英、三宅喜义、谷内上智春、山城俊介。 此外，对其他参与了评审工作的人员也一并表示感谢。 另外，还要向软银出版股份有限公司的图书总编野泽喜美男和第一图书编辑部的松本香织表示感谢。当我们一起商量这本书的选题时，他们都表示“这一定会是一本好书”，这让我倍受鼓舞。最后要感谢我最爱的妻子和两个儿子，以及总是精神满满地支持我的岳母大人。 结城浩 2001 年3 月 于武藏野 写于“修订版”前 《图解设计模式》一书自2001 年初版发行以来，承蒙各位读者的厚爱，在此再次向各位读者表达我最真挚的感谢。 在这次“修订版”中，笔者重新全面地审视了本书的内容和表述。在修订中，也参考了读者朋友们发送给我的无数反馈意见和建议，真心谢谢你们。希望本书也能在读者朋友的工作和学习中发挥些许作用。 结城浩 2004 年6 月