好书整理系列之-设计模式:可复用面向对象软件的基础 6


第6章结论
或许有人会认为本书并多大贡献。毕竟,它没有提出任何前所未见的新算法或者新程序
设计技术。本书既没有给出一种严格的系统设计方法,也没有提出一套新的设计理论-它
只是将现有的一些设计加以文档化。也许你会认为它是一本合适的入门指南,但对有经验的
面向对象设计人员却并无多大帮助。
我们希望你不会有上面这样的想法。这是因为对设计模式的分类整理是重要的,它为我
们使用的各种技术提供了标准的名称和定义。如果我们不研究软件中的设计模式,就无法对
它们进行改进,更难以提出新的设计模式。
本书仅仅是一个开始。它讨论了面向对象设计专家们所使用的某些最常见的设计模式,
而人们常常也会在口头交谈或分析已有系统时听到和学到这些设计模式。曾有人看了本书的
初稿后也将其使用的设计模式写下来,因此,本书就更应起到抛砖引玉的作用。我们希望这
将标志着一场把软件从业人员专门知识和技能加以文档化运动的开始。
本章的讨论内容包括我们认为设计模式将带来的巨大影响,设计模式与其他设计工作的
关系,以及你怎样发现和整理设计模式。
6.1 设计模式将带来什么
根据我们日常使用设计模式的经验,我们认为它们将在以下几个方面影响你设计面向对
象软件的方式。
6.2 一套通用的设计词汇
对使用传统语言的程序设计专家们的研究表明,其知识和经验并非是简单地围绕语法来
组织的,而是围绕着诸如算法、数据结构、习惯用语[ A S 8 5 , C o p 9 2 , C u r 8 9 , S S 8 6 ]和满足某特定
目标的计划[ S E 8 4 ]等更大的概念结构来组织的。设计者可能考虑得更多的不是用来记录设计
的表示方式,而是如何把当前的设计问题与已知的计划、算法、数据结构和习惯用语等进行
匹配。
计算机科学家们对算法和数据结构进行命名和分类,但我们却很少为其他类型的模式命
名。设计模式为设计者们交流讨论、书写文档以及探索各种不同设计提供了一套通用的设计
词汇。设计模式使你可以在比设计表示或编程语言更高的抽象级别上谈论一个系统,从而降
低了其复杂度。设计模式提高了你的设计及你与同事讨论这些设计的层次。
一旦你吸收了本书中的各设计模式,你的设计词汇就几乎肯定要有所改变。你会直接使
用这些模式的名称来表示某个设计,比如你会说:“这里我们使用观察者模式”,或者,“让我
们从这些类中抽出一个S t r a t e g y”。
6.3 书写文档和学习的辅助手段
了解本书中的各设计模式可使你更容易理解已有的系统。大多数规模较大的面向对象系
统都使用了这些设计模式。人们在学习面向对象编程时常常抱怨系统中继承的使用令人费解
以及难于理解控制流程。这在很大程度上是由于他们未能理解该系统中的设计模式。学习这
些设计模式将有助于你理解已有的面向对象系统。
这些设计模式也能提高你的设计水平。它们为你提供一些常见问题的解决方案。当然,
如果你长期从事面向对象系统的工作,迟早你也会自己学到这些设计模式。但通过本书你可
以学得更快。学好这些模式将有助于一个新手做出像专家一样的设计。
而且,按照一个系统所使用的设计模式来描述该系统可以使他人理解起来容易得多,否
则,就必须对该系统的设计进行逆向工程来弄清其使用的设计模式。有一套通用的设计词汇
的好处是你不必描述整个设计模式,而只要使用它的名字,当他人读到这个名字就会理解你
的设计。当然如果读者不知道这个设计模式,他就必须先去查找学习该模式,即使这样也还
是比逆向工程来的容易。
我们在自己的设计中使用这些模式,并发现它们有很多好处。我们还以某些可争议的幼
稚方式使用这些设计模式。我们用它们来为类命名,思考和传授优秀的设计,并用一连串的
设计模式来描述我们的设计。很容易想出更复杂的使用设计模式的方式,比如基于模式的
C A S E工具或超文本文档。不过即使没有复杂的工具,设计模式对我们也还是很有帮助的。
6.4 现有方法的一种补充
面向对象设计方法可用来促进良好的设计,教新手如何设计,以及对设计活动进行标准
化。一个设计方法通常定义了一组(常常是图形化的)用来为设计问题各方面进行建模的记
号(n o t a t i o n),以及决定在什么样情况下以什么样的方式使用这些记号的一组规则。设计方
法通常描述一个设计中出现的问题,如何解决这些问题,以及如何评估一个设计。但设计方
法还不能描述设计专家的经验。
我们相信设计模式是面向对象设计方法所缺少的一块重要内容。这些设计模式展示了如
何使用诸如对象、继承和多态等基本技术。它们也展示了如何以算法、行为、状态或者需生
成的对象类型来将一个系统参数化。设计模式使你可以更多地描述“为什么”这样设计而不
仅仅是记录你的设计结果。设计模式的适用性、效果和实现部分都会帮助指导你做出各个必
要的设计决定。
设计模式在将一个分析模型转换为一个实现模型的时候特别有用。尽管许多人声称面向
对象分析可以平滑地向设计转换,但实践表明远非如此。一个灵活的可复用的设计常会包含
一些分析模型中没有的对象。另外,你所使用的编程语言和类库也会影响设计。因此,为使
设计可复用,常常需要重新设计分析模型。许多设计模式描述了这样的问题,这也是为什么
我们称之为设计模式的原因。
一个成熟的设计方法不仅要有设计模式,还可有其他类型的模式,如分析模式,用户界
面设计模式,或者性能调节模式等等。但是设计模式是最主要的部分,这在以前却被忽略了。
6.5 重构的目标
开发可复用软件的一个问题是开发者常常不得不重新组织或重构[ O J 9 0 ]软件系统。设计
模式可以帮助你重新组织一个设计,同时还能减少以后的重构工作。
面向对象软件的生命周期常分为几个阶段。Brain Foote将其分为原型阶段、扩展阶段和


巩固阶段三个阶段[ F o o 9 2 ]。
在原型阶段,首先建立一个快速原型,在此基础上进行增量式的修改,直至能满足一组
基本需求,然后进入“青春期”。此时,软件中的类层次通常直接反映了原始问题域中的各个
实体。该阶段主要的复用方式是通过继承进行白箱复用。
一旦软件进入青春期并交付使用,其演化就由以下两个相互冲突的要求来决定: ( 1 )该软
件必须满足更多的需求。( 2 )该软件必须更易于复用。新的需求常常要求加入新的类和操作甚
至增加整个类层次。于是该软件就要经过一个扩展阶段来满足新的需求。然而,这种扩展并
不能持续很久。软件的不断扩展将使其变得过于滞胀僵硬而难以进一步修改。软件类层次不
再与任何问题域匹配,而是多个问题域的混合反映,并且类中定义了许多不相关的操作和实
例变量。
该软件若要继续演化就必须重新组织,这个过程称为重构(r e f a c t o r i n g)。框架常常在这
个阶段出现。重构工作包括将类拆分为专用和通用的构件,把各个操作在类层次上提或下放
到合适的类中,并使各个类的接口合理化。这个巩固阶段将会产生许多新类型的对象,它们
通常是通过分解而不是继承原有的对象而得到的。因而黑箱复用代替了白箱复用。满足更多
需求和达到更高可复用性的要求推动面向对象软件不断重复扩展和巩固这两个阶段-扩展
以满足新的需求,而巩固使软件更为通用(参见下图)。
这个循环是不可避免的。但好的设计者不仅知道哪些变化会促使重构,而且还知道哪些
类和对象结构能够避免重构-它们的设计对于需求变化具有健壮性。对需求进行彻底分析
有助于突出在软件的生命周期中易于发生变化的那些需求,而一个好的设计应对这些变化保
持稳定。
我们的设计模式记录了许多重构产生的设计结构。在设计初期使用这些模式可以防止以
后的重构。不过你即使是在系统建成以后才了解如何使用这些模式,它们仍可以教你如何修
改你的系统。设计模式为你的重构提供了目标。
6.6 本书简史
分类整理设计模式肇始于E r i c h的博士论文[Gam91, Gam92]的部分工作。他的论文中大约
有占本书半数的模式。到O O P S L A’9 1召开的时候它已正式成为一项独立的工作,并且
R i c h a r d已加入进来与E r i c h一道从事这项工作。不久J o h n也加入进来。到O O P S L A’9 2的时候,
R a l p h也已加入到这个小组中。我们曾试图使我们的工作成果可以发表在E C O O P’9 3上,但
我们很快意识到篇幅太长的论文是不会被录用的。所以我们将其简化为一个摘要发表在那次
会议上。在那以后我们决定把我们分类整理的模式写成一本书。


扩展
进一步的复用进一步的需求
生成原型巩固
在此过程中,我们改动了一些模式的名称。“Wr a p p e r”变成了“ D e c o r a t o r”,“G l u e”变
成了“F a c a d e”,“S o l i t a i r e”变成了“S i n g l e t o n”,以及“Wa l k e r”变成了“Vi s i t o r”,并删掉
了几个看起来不那么重要的模式。不过自1 9 9 2年以来,这个分类体系中包含哪些模式没有多
大变化,但各模式本身却有了巨大改进。
实际上,注意到某些东西是一个模式还是整个工作中相对容易的部分。我们四个人都经
常从事建造面向对象系统的工作,发现当接触到足够多的系统时,发现模式并不困难。然而
描述模式却要困难得多。
当你回过头来看你已经建好的一些系统时,会发现所做的工作中就存在着模式。但是,
要很好地描述它们以使不熟悉的人也能理解并意识到它们为什么重要就很困难了。专家们能
立即从我们模式的早期版本中意识到它们的价值,但也只有这些实际已经用过这些模式的人
才能理解它们。
由于本书的主要目的之一在于教设计新手进行面向对象设计,所以我们必须改进模式的
分类描述。我们将每个模式的篇幅进行了扩充,其中加入了较具体的说明动机的例子和示例
代码,同时对模式的权衡以及实现模式的不同方式也进行了检查。这样就使模式学起来更容
易一些。
在过去的一年中所做的另一个重要修改是更加强调一个模式所针对的问题。模式是问题
的解决方案,是可以被重复使用的技术手段,这很容易明白;困难的是知道在什么情况下使
用这个模式才是恰当的,也就是要刻画这个模式所针对的问题及其上下文,只有在这样的上
下文中,这个模式才是最优解。一般而言,了解“做什么”要比“为什么”来的容易;而一
个模式的“为什么”就是它要解决的问题。了解一个模式的目的也是重要的,它可以帮助我
们选择要使用的模式,也可以帮助我们理解已有系统的设计。作为一个模式的作者,即使你
已经知道了解决方案,你还是必须回过头来确定并刻画该模式所解决的问题。
6.7 模式界
我们并不是唯一的对写书来分类整理专家们使用的设计模式感兴趣的小组。我们属于一
个更大的圈子,这个圈子里的人们对模式特别是有关软件的模式很感兴趣。建筑师
Christopher Alexander第一个研究了建筑物和社区的模式,并开发了一个“模式语言”来生成
它们。他的工作一次次地启发了我们。所以有必要将我们的工作与他的工作作一个比较,然
后我们将看看其他有关软件模式方面的工作。
6.8 Alexander的模式语言
我们的工作在许多方面和A l e x a n d e r的类似。二者都是在观察已有系统的基础上,发现其
中的模式,都有描述模式的模板(尽管我们的模板有很大的不同),都是用自然语言和许多例
子而不是用形式语言来描述模式,都给出了每个模式背后的原理。
不过我们的工作也在许多方面不同于A l e x a n d e r的模式语言:
1) 人类从事建筑活动已有几千年的历史,积累下来许多经典的案例可供参考。相对而言
建造软件系统的历史就短的多,很少有系统可称得上经典。
2) Alexander给出了他的模式的使用顺序,而我们没有。
3) Alexander的模式强调它们所针对的问题,而设计模式则更详细的描述了解决方案。


4 ) A l e x a n d e r声称他的模式可以生成完整的建筑,而我们不能说我们的模式可以生成完整
的程序。
A l e x a n d e r声称可以通过简单地一个接一个地使用他的模式来设计一所房屋。这类似于一
些面向对象设计方法学家的目标,他们也给出了一步步地进行软件设计的规则。A l e x a n d e r并
不否认创造的必要性,他的一些模式要求设计者理解所设计建筑物的使用者的生活习惯。而
且,他对设计的“诗意”的信仰暗示了存在某种高于模式语言本身的专业水平。不过他对
模式怎样生成设计的描述却意味着模式语言可使设计活动成为一种确定的和可重复的过程。
A l e x a n d e r的观点启发我们关注设计中的权衡问题-多种“力”共同决定了最终的设计
结果。在他的影响下,我们慎重考虑了我们的设计模式的适用性及其效果。这也使我们不再
试图定义模式的形式化表示。这是因为尽管这种形式化表示将使模式自动化成为可能,但目
前更重要的是探索新的模式而不是将模式形式化。
依据A l e x a n d e r的观点,本书的模式不能形成一个模式语言。考虑到人们建造的软件系统
的多样性,我们很难给出一个“完备”的模式集合来指导人们一步步地设计出完整的应用。
尽管对于某些特定类型的应用(例如报表生成系统)我们可以做到这一点。然而本书的模式
体系仅仅是相关模式的集合,我们不能视之为一种模式语言。
实际上,我们认为永远也不会有一个完备的软件模式语言。当然我们可以使模式系统更
加完整,如可以加入包括框架及其怎样使用框架[ J o h 9 2 ],用户界面设计模式[ B J 9 4 ],分析模
式[ C o a 9 2 ],以及软件开发过程中的其他各个方面内容。设计模式仅仅是一个更大的软件模式
语言的一部分。
6.9 软件中的模式
我们第一次集体研究软件体系结构是在O O P S L A’9 1大会中一次由Bruce Anderson主持的
讨论会上。那次讨论会致力于为软件体系结构设计者编写一本手册(从本书看来,我们认为
“体系结构百科全书”这个名称要比“体系结构手册”更好一些)。此后又举行了一系列的会
议,最近的一次是1 9 9 4年8月召开的第一届程序模式语言大会,这次会议建立了一个群体,其
兴趣是将软件经验文档化。
当然,也有其他人抱有同样的目标。Danald Knuth的《计算机程序设计的艺术》[ K n u 7 3 ]
就是分类整理软件知识的最早尝试之一,只是他着重于描述算法。事实证明,即便如此,这
项工作也还是工程浩大而难以完成。《Graphics Gems》系列[Gla90, Arv91, Kir92]是另一个同
样着重于算法的设计知识分类体系。美国国防部发起的领域专用软件结构计划集中收集有关
体系结构方面的信息。基于知识的软件工程界试图一般地表述软件相关知识。此外还有许多
其他小组在为与我们相似的目标而努力。
James Coplien的《Advanced C++: Programming Styles and Indioms》[ C o p 9 2 ]一书也对我
们产生了影响。相对于我们的设计模式,该书中描述的模式更加针对C + +语言,而且还包含
了许多低层的模式。不过正如在我们的模式中已指出的那样,二者之间是有一些重复的。J i m
在模式界很活跃,目前他正在研究那些用来描述软件开发组织中人的角色的模式。
你还可以从其他许多地方找到对模式的描述。Kent Beck 是软件界中首先倡导学习
Christopher Alexander的工作的先驱者之一。在1 9 9 3年他开始在《The Smalltalk Report》上撰
2 3 6 设计模式:可复用面向对象软件的基础

参见“The poetry of the language” [ A I S + 7 7 ]
写关于S m a l l t a l k模式的一个专栏。Peter Coad开始收集模式也有一段时间了。在我们看来,他
的关于模式的论文主要讨论的是分析模式[ C o a 9 2 ]。我们知道他还在继续从事这方面的工作,
但我们没有看到他最新的成果。我们也听说有好几本关于模式的书正在撰写之中,但目前一
本也没有看到,所以我们只能告诉你它们就要出现了。其中有一本书将来源于P a t t e r n
Language of Programming会议。
6.10 邀请参与
如果你对模式感兴趣的话,你能做些什么呢?首先,你可以在你的设计工作中使用这些
设计模式,并寻找其他可用的设计模式。接下来几年里将会有许多有关模式的书和文章出现,
所以不愁没地方找新的模式。不断积累和使用你的模式词汇,在与他人讨论你的设计时你可
以使用它们,在构思和书写你的设计时也可以使用它们。
其次,提出你的批评。这个设计模式体系是许多人辛勤工作的成果,除了我们之外,还
有几十个评论者提出了反馈意见。如果你发现了存在的问题或者觉得某些地方需要进一步解
释的话,请和我们联系。同样,对于其他模式体系,也请给予你的反馈意见。模式的一个重
要好处在于它提供的设计决策不再是模糊的直觉意向,模式的作者可以明确地说明他在各需
求要素间所作的权衡取舍。这就为发现并与作者讨论其模式的不足之处提供了方便。你可以
充分利用模式这个优越性。
再次,寻找你使用过的模式,并把它们写下来。把它们作为你的文档的组成部分,给别
人看。你并不一定要在研究机构里才可以发掘模式。实际上,如果你没有某方面的实践经验,
要发现相关的模式几乎是不可能的。你尽管写下你的模式体系,但一定要让其他人来帮助你
使之成形!
6.11 临别感想
最佳的设计要用到许多设计模式,它们契合交织,形成一个更大的整体。正如C h r i s t o p h e r
A l e x a n d e r所说:
以一种松散的方式把一些模式串接在一起来建造建筑是可能的。这样的建筑仅仅是
一些模式的堆砌,而不紧凑。这不够深刻。然而另有一种组合模式的方式,许多模式重
叠在同一个物理空间里:这样的建筑非常紧凑,在一小块空间里集成了许多内涵;由于
这种紧凑,它变得深刻。


 

  • 0
    点赞
  • 0
    收藏
  • 打赏
    打赏
  • 0
    评论
书名: 设计模式复用面向对象软件基础 英文原书名: Design Patterns:Elements of Reusable Object-Oriented software 作者: Erich Gamma 等 译者: 李英军 马晓星 蔡敏 刘建中 书号: 7-111-07575-7 页码: 254 定价: ¥35.00 会员价: ¥31.50 币值: 315 出版日期: 2000-9-1 本书设计实例从面向对象设计中精选出23个设计模式,总结了面向对象设计中最有价值经验,并且用简洁复用形式表达出来。本书分类描述了一组设计良好,表达清楚软件设计模式,这些模式在实用环境下有特别有用。 -------- 目 录 序言 前言 读者指南 第1章 引言 1 1.1 什么是设计模式 2 1.2 Smalltalk MVC中设计模式 3 1.3 描述设计模式 4 1.4 设计模式编目 5 1.5 组织编目 7 1.6 设计模式怎样解决设计问题 8 1.6.1 寻找合适对象 8 1.6.2 决定对象粒度 9 1.6.3 指定对象接口 9 1.6.4 描述对象实现 10 1.6.5 运用复用机制 13 1.6.6 关联运行时刻和编译时刻 结构 15 1.6.7 设计应支持变化 16 1.7 怎样选择设计模式 19 1.8 怎样使用设计模式 20 第2章 实例研究设计一个文档编 辑器 22 2.1 设计问题 23 2.2 文档结构 23 2.2.1 递归组合 24 2.2.2 图元 25 2.2.3 组合模式 27 2.3 格式化 27 2.3.1 封装格式化算法 27 2.3.2 Compositor和Composition 27 2.3.3 策略模式 29 2.4 修饰用户界面 29 2.4.1 透明围栏 29 2.4.2 Monoglyph 30 2.4.3 Decorator 模式 32 2.5 支持多种视感标准 32 2.5.1 对象创建抽象 32 2.5.2 工厂类和产品类 33 2.5.3 Abstract Factory模式 35 2.6 支持多种窗口系统 35 2.6.1 我们是否以使用Abstract Factory 模式 35 2.6.2 封装实现依赖关系 35 2.6.3 Window和WindowImp 37 2.6.4 Bridge 模式 40 2.7 用户操作 40 2.7.1 封装一个请求 41 2.7.2 Command 类及其子类 41 2.7.3 撤消和重做 42 2.7.4 命令历史记录 42 2.7.5 Command 模式 44 2.8 拼写检查和断字处理 44 2.8.1 访问分散信息 44 2.8.2 封装访问和遍历 45 2.8.3 Iterator类及其子类 46 2.8.4 Iterator模式 48 2.8.5 遍历和遍历过程中动作 48 2.8.6 封装分析 48 2.8.7 Visitor 类及其子类 51 2.8.8 Visitor 模式 52 2.9 小结 53 第3章 创建型模式 54 3.1 Abstract Factory(抽象工厂)— 对象创建型模式 57 3.2 Builder(生成器)—对象创建型 模式 63 3.3 Factory Method(工厂方法)— 对象创建型模式 70 3.4 Prototype(原型)—对象创建型 模式 87 3.5 Singleton(单件)—对象创建型 模式 84 3.6 创建型模式讨论 89 第4章 结构型模式 91 4.1 Adapter(适配器)—类对象结构型 模式 92 4.2 Bridge(桥接)—对象结构型 模式 100 4.3 Composite(组成)—对象结构型 模式 107 4.4 Decorator(装饰)—对象结构型 模式 115 4.5 FACADE(外观)—对象结构型 模式 121 4.6 Flyweight(享元)—对象结构型 模式 128 4.7 Proxy(代理)—对象结构型 模式 137 4.8 结构型模式讨论 144 4.8.1 Adapter与Bridge 144 4.8.2 Composite、Decorator与Proxy 145 第5章 行为模式 147 5.1 CHAIN OF RESPONSIBIL ITY(职责链) —对象行为型模式 147 5.2 COMMAND(命令)—对象行为型 模式 154 5.3 INTERPRETER(解释器)—类行为型 模式 162 5.4 ITERATOR(迭代器)—对象行为型 模式 171 5.5 MEDIATOR(中介者)—对象行为型 模式 181 5.6 MEMENTO(备忘录)—对象行为型 模式 188 5.7 OBSERVER(观察者)—对象行为型 模式 194 5.8 STATE(状态)—对象行为型模式 201 5.9 STRATEGY(策略)—对象行为型 模式 208 5.10 TEMPLATE METHOD(模板方法) —类行为型模式 214 5.11 VISITOR(访问者)—对象行为型 模式 218 5.12 行为模式讨论 228 5.12 1 封装变化 228 5.12.2 对象作为参数 228 5.12.3 通信应该被封装还是被分布 229 5.12.4 对发送者和接收者解耦 229 5.12.5 总结 231 第6章 结论 232 6.1 设计模式将带来什么 232 6.2 一套通用设计词汇 232 6.3 书写文档和学习辅助手段 232 6.4 现有方法一种补充 233 6.5 重构目标 233 6.6 本书简史 234 6.7 模式界 235 6.8 Alexander 模式语言 235 6.9 软件模式 236 6.10 邀请参与 237 6.11 临别感想 237 附录A 词汇表 238 附录B 图示符号指南 241 附录C 基本类 244 参考文献 249
基本信息 原书名 Design Patterns:Elements of Reusable Object-Oriented software 原出版社 Addison Wesley/Pearson 作者 (美)Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides [作译者介绍] 译者 李英军 马晓星 蔡敏 刘建中 丛书名 计算机科学丛书 出版社机械工业出版社 ISBN7111075757 上架时间2005-7-19 出版日期2004 年9月 开本16开 页码254 版次1-11 内容简介   本书结合设计实例从面向对象设计中精选出23个设计模式,总结了面向对象设计中最有价值经验,并且用简洁复用形式表达出来。本书分类描述了一组设计良好、表达清楚软件设计模式,这些模式在实用环境下特别有用。本书适合大学计算机专业学生、研究生及相关人员参考。       [strong][font color="#ff0000"]书评[/font][/strong][font color="#ff0000"]       “这本众人期待确达到了预期全部效果。该书云集了经过时间考验用设计。作者从多年面向对象设计经验中精选了23个模式,这构成了该书精华部份,每一个精益求精优秀程序员都应拥有这本《设计模式》。”--larry o'brien, software development       “[设计模式]在实用环境下特别有用,因为它分类描述了一组设计良好,表达清楚面向对象软件设计模式。整个设计模式领域还很新,本书四位作者也许已占据了这个领域造诣最深专家中半数,因而他们定义模式方法以作为后来者榜样。如果要知道怎样恰当定义和描述设计模式,我们应该以从他们那儿获得启发”--steve billow, journal of object-oriented programming       “总来讲,这本书表达了一种极有价值东西。对软件设计领域有着独特贡献,因为它捕获了面向对象设计有价值经验,并且用简洁复用形式表达出来。它将成为我在寻找面向对象设计思想过程中经常翻阅一本书﹕这正是复用真实含义所在,不是吗﹖”--sanjiv gossain, journal of object-oriented programming [/font] 目 录 序言 前言 读者指南 第1章 引言 1 1.1 什么是设计模式 2 1.2 smalltalk mvc中设计模式 3 1.3 描述设计模式 4 1.4 设计模式编目 5 1.5 组织编目 7 1.6 设计模式怎样解决设计问题 8 1.6.1 寻找合适对象 8 1.6.2 决定对象粒度 9 1.6.3 指定对象接口 9 1.6.4 描述对象实现 10 1.6.5 运用复用机制 13 1.6.6 关联运行时刻和编译时刻 结构 15 1.6.7 设计应支持变化 16 1.7 怎样选择设计模式 19 .1.8 怎样使用设计模式 20 第2章 实例研究设计一个文档编 辑器 22 2.1 设计问题 23 2.2 文档结构 23 2.2.1 递归组合 24 2.2.2 图元 25 2.2.3 组合模式 27 2.3 格式化 27 2.3.1 封装格式化算法 27 2.3.2 compositor和composition 27 2.3.3 策略模式 29 2.4 修饰用户界面 29 2.4.1 透明围栏 29 2.4.2 monoglyph 30 2.4.3 decorator 模式 32 2.5 支持多种视感标准 32 2.5.1 对象创建抽象 32 2.5.2 工厂类和产品类 33 2.5.3 abstract factory模式 35 2.6 支持多种窗口系统 35 2.6.1 我们是否以使用abstract factory 模式 35 2.6.2 封装实现依赖关系 35 2.6.3 window和windowimp 37 2.6.4 bridge 模式 40 2.7 用户操作 40 2.7.1 封装一个请求 41 2.7.2 command 类及其子类 41 2.7.3 撤消和重做 42 2.7.4 命令历史记录 42 2.7.5 command 模式 44 2.8 拼写检查和断字处理 44 2.8.1 访问分散信息 44 2.8.2 封装访问和遍历 45 2.8.3 iterator类及其子类 46 2.8.4 iterator模式 48 2.8.5 遍历和遍历过程中动作 48 2.8.6 封装分析 48 2.8.7 visitor 类及其子类 51 2.8.8 visitor 模式 52 2.9 小结 53 第3章 创建型模式 54 3.1 abstract factory(抽象工厂)— 对象创建型模式 57 3.2 builder(生成器)—对象创建型 模式 63 3.3 factory method(工厂方法)— 对象创建型模式 70 3.4 prototype(原型)—对象创建型 模式 87 3.5 singleton(单件)—对象创建型 模式 84 3.6 创建型模式讨论 89 第4章 结构型模式 91 4.1 adapter(适配器)—类对象结构型 模式 92 4.2 bridge(桥接)—对象结构型 模式 100 4.3 composite(组成)—对象结构型 模式 107 4.4 decorator(装饰)—对象结构型 模式 115 4.5 facade(外观)—对象结构型 模式 121 4.6 flyweight(享元)—对象结构型 模式 128 4.7 proxy(代理)—对象结构型 模式 137 4.8 结构型模式讨论 144 4.8.1 adapter与bridge 144 4.8.2 composite、decorator与proxy 145 第5章 行为模式 147 5.1 chain of responsibil ity(职责链) —对象行为型模式 147 5.2 command(命令)—对象行为型 模式 154 5.3 interpreter(解释器)—类行为型 模式 162 5.4 iterator(迭代器)—对象行为型 模式 171 5.5 mediator(中介者)—对象行为型 模式 181 5.6 memento(备忘录)—对象行为型 模式 188 5.7 observer(观察者)—对象行为型 模式 194 5.8 state(状态)—对象行为型模式 201 5.9 strategy(策略)—对象行为型 模式 208 5.10 template method(模板方法) —类行为型模式 214 5.11 visitor(访问者)—对象行为型 模式 218 5.12 行为模式讨论 228 5.12 1 封装变化 228 5.12.2 对象作为参数 228 5.12.3 通信应该被封装还是被分布 229 5.12.4 对发送者和接收者解耦 229 5.12.5 总结 231 第6章 结论 232 6.1 设计模式将带来什么 232 6.2 一套通用设计词汇 232 6.3 书写文档和学习辅助手段 232 6.4 现有方法一种补充 233 6.5 重构目标 233 6.6 本书简史 234 6.7 模式界 235 6.8 alexander 模式语言 235 6.9 软件模式 236 6.10 邀请参与 237 6.11 临别感想 237 附录a 词汇表 238 附录b 图示符号指南 241 附录c 基本类 244 参考文献 249   前 言      本书并不是一本介绍面向对象技术或设计书,目前已有不少好书介绍面向对象技术或设计。本书假设你至少已经比较熟悉一种面向对象编程语言,并且有一定面向对象设计经验。当我们提及“类型”和“多态”,或“接口”继承与“实现”继承关系时,你应该对这些概念了然于胸,而不必迫不及待地翻阅手头字典。      另外,这也不是一篇高级专题技术论文,而是一本关于设计模式书,它描述了在面向对象软件设计过程中针对特定问题简洁而优雅解决方案。设计模式捕获了随时间进化与发展问题求解方法,因此它们并不是人们从一开始就采用设计方案。它们反映了不为人知重新设计和重新编码成果,而这些都来自软件开发者为了设计出灵活复用软件而长时间进行艰苦努力。设计模式捕获了这些解决方案,并用简洁易用方式表达出来。      设计模式并不要求使用独特语言特性,也不采用那些足以使你朋友或老板大吃一惊神奇编程技巧。所有模式均以用标准面向对象语言实现,这也许有时会比特殊解法多费一些功夫,但是为了增加软件灵活性和复用性,多做些工作是值得。      一旦你理解了设计模式并且有了一种“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.html.      E.G. 于加州Mountain View    .  R.H. 于蒙特利尔      R.J. 于伊利诺Urbana      J.V. 于纽约 Hawthorne      1994年8月    序言    所有结构良好面向对象软件体系结构中都包含了许多模式。实际上,当我评估一个面向对象系统质量时,所使用方法一就是要判断系统设计者是否强调了对象公共协同关系。在系统开发阶段强调这种机制优势在于,它能使所生成系统体系结构更加精巧、简洁和易于理解,其程度远远超过了未使用模式体系结构。    模式在构造复杂系统时重要性早已在其他领域中被认。特别地,Christopher Alexander和他同事们能最先将模式语言(pattern language)应用于城市建筑领域,他思想和其他人贡献已经根植于面向对象软件界。简而言软件领域中设计模式为开发人员提供了一种使用专家设计经验有效途径。    在本书中,Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides介绍了设计模式原理,并且对这些设计模式进行了分类描述。因此,该书做出了两个重要贡献首先,它展示了模式在建造复杂系统过程中所处角色;其次,它为如何引用一组精心设计模式提供了一个实用方法,以帮助实际开发者针对特定应用问题使用适当模式进行设计。    我曾荣幸地有机会与本书部分作者一同进行体系结构设计工作,从他们身上我学到了许多东西,并相信通过阅读该书你同样也会受益匪浅。    Rational 软件公司首席科学家 Grady Booch

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论

打赏作者

coolstar

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值