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

Visual C++ 专栏收录该内容
17 篇文章 0 订阅


第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
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
通篇都是以情景对话形式,用多个小故事或编程示例来组织讲解GoF(设计模式经典名著——Design Patterns: Elements of Reusable Object-Oriented Software,中译本名为《设计模式——复用面向对象软件基础四位作者Erich Gamma、Richard Helm、Ralph Johnson,以及John Vlissides,这四人常被称为 Gang of Four,即四人组,简称GoF)总结23个设计模式。本书共分为29章。其中,第1、3、4、5章着重讲解了面向对象意义、好处以及几个重要设计原则;第2章,以及第6到第28章详细讲解了23个设计模式;第29章是对设计模式全面总结。附录部分是通过一个例子演变为初学者介绍了面向对象基本概念。本书特色是通过小菜与大鸟趣味问答,在讲解程序不断重构和演变过程中,把设计模式学习门槛降低,让初学者以更加容易地理解——为什么这样设计才是好?是怎样想到这样设计?以达到不但授以“鱼”,还授以“渔”。引导读者体会设计演变过程中蕴藏大智慧。 本书适合编程初学者或希望在面向对象编程上有所提高开发人员阅读。 目 录 第1章 代码无错就是优?——简单工厂模式 1 1.1 面试受挫 1 1.2 初学者代码毛病 2 1.3 代码规范 2 1.4 面向对象编程 4 1.5 活字印刷,面向对象 4 1.6 面向对象好处 5 1.7 复制vs.复用 6 1.8 业务封装 6 1.9 紧耦合vs.松耦合 8 1.10 简单工厂模式 10 1.11 UML类图 12 第2章 商场促销——策略模式 17 2.1 商场收银软件 17 2.2 增加打折 18 2.3 简单工厂实现 19 2.4 策略模式 22 2.5 策略模式实现 25 2.6 策略与简单工厂结合 27 2.7 策略模式解析 28 第3章 拍摄UFO——单一职责原则 30 3.1 新手机 30 3.2 拍摄 30 3.3 没用东西 31 3.4 单一职责原则 31 3.5 方块游戏设计 31 3.6 手机职责过多吗? 33 第4章 考研求职两不误——开放-封闭原则 34 4.1 考研失败 34 4.2 开放-封闭原则 35 4.3 何时应对变化 36 4.4 两手准备,并全力以赴 37 第5章 会修电脑不会修收音机?——依赖倒转原则 38 5.1 MM请求修电脑 38 5.2 电话遥控修电脑 39 5.3 依赖倒转原则 40 5.4 里氏代换原则 41 5.5 修收音机 43 第6章 穿什么有这么重要?——装饰模式 44 6.1 穿什么有这么重要? 44 6.2 小菜扮靓第一版 45 6.3 小菜扮靓第二版 47 6.4 装饰模式 50 6.5 小菜扮靓第三版 53 6.6 装饰模式总结 56 第7章 为别人做嫁衣——代理模式 57 7.1 为别人做嫁衣! 57 7.2 没有代理代码 58 7.3 只有代理代码 60 7.4 符合实际代码 61 7.5 代理模式 63 7.6 代理模式应用 65 7.7 秀才让小六代其求婚 66 第8章 雷锋依然在人间——工厂方法模式 67 8.1 再现活雷锋 67 8.2 简单工厂模式实现 68 8.3 工厂方法模式实现 69 8.4 简单工厂vs.工厂方法 71 8.5 雷锋工厂 72 第9章 简历复印——原型模式 77 9.1 夸张简历 77 9.2 简历代码初步实现 78 9.3 原型模式 80 9.4 简历原型实现 82 9.5 浅复制与深复制 84 9.6 简历深复制实现 87 9.7 复制简历vs.手写求职信 89 第10章 考题抄错会做也白搭——模板方法模式 90 10.1 选择题不会做,蒙呗! 90 10.2 重复=易错+难改 91 10.3 提炼代码 93 10.4 模板方法模式 96 10.5 模板方法模式特点 98 10.6 主观题,看你怎么蒙 98 第11章 无熟人难办事?——迪米特法则 100 11.1 第一天上班 100 11.2 无熟人难办事 100 11.3 迪米特法则 102 第12章 牛市股票还会亏钱?——外观模式 103 12.1 牛市股票还会亏钱? 103 12.2 股民炒股代码 104 12.3 投资基金代码 106 12.4 外观模式 108 12.5 何时使用外观模式 110 第13章 好菜每回味不同——建造者模式 112 13.1 炒面没放盐 112 13.2 建造小人一 113 13.3 建造小人二 114 13.4 建造者模式 115 13.5 建造者模式解析 118 13.6 建造者模式基本代码 119 第14章 老板回来,我不知道——观察者模式 123 14.1 老板回来?我不知道! 123 14.2 双向耦合代码 124 14.3 解耦实践一 126 14.4 解耦实践二 128 14.5 观察者模式 131 14.6 观察者模式特点 134 14.7 观察者模式不足 135 14.8 事件委托实现 136 14.9 事件委托说明 139 14.10 石守吉失手机后委托 140 第15章 就不能不换DB吗?——抽象工厂模式 141 15.1 就不能不换DB吗? 141 15.2 最基本数据访问程序 142 15.3 用了工厂方法模式数据访问程序 143 15.4 用了抽象工厂模式数据访问程序 146 15.5 抽象工厂模式 149 15.6 抽象工厂模式优点与缺点 151 15.7 用简单工厂来改进抽象工厂 151 15.8 用反射+抽象工厂数据访问程序 154 15.9 用反射+配置文件实现数据访问程序 157 15.10 无痴迷,不成功 157 第16章 无尽加班何时休——状态模式 158 16.1 加班,又是加班! 158 16.2 工作状态-函数版 159 16.3 工作状态-分类版 160 16.4 方法过长是坏味道 162 16.5 状态模式 163 16.6 状态模式好处与用处 165 16.7 工作状态-状态模式版 166 第17章 在NBA我需要翻译——适配器模式 171 17.1 在NBA我需要翻译! 171 17.2 适配器模式 171 17.3 何时使用适配器模式 174 17.4 篮球翻译适配器 174 17.5 适配器模式.NET应用 178 17.6 扁鹊医术 178 第18章 如果再回到从前——备忘录模式 180 18.1 如果再给我一次机会…… 180 18.2 游戏存进度 180 18.3 备忘录模式 183 18.4 备忘录模式基本代码 184 18.5 游戏进度备忘 186 第19章 分公司=一部门——组合模式 189 19.1 分公司不就是一部门吗? 189 19.2 组合模式 190 19.3 透明方式与安全方式 193 19.4 何时使用组合模式 194 19.5 公司管理系统 194 19.6 组合模式好处 198 第20章 想走?以!先买票——迭代器模式 200 20.1 乘车买票,不管你是谁! 200 20.2 迭代器模式 201 20.3 迭代器实现 202 20.4 .NET迭代器实现 206 20.5 迭代高手 208 第21章 有些类也需计划生育——单例模式 209 21.1 类也需要计划生育 209 21.2 判断对象是否是null 210 21.3 生还是不生是自己责任 213 21.4 单例模式 214 21.5 多线程时单例 216 21.6 双重锁定 217 21.7 静态初始化 218 第22章 手机软件何时统一——桥接模式 220 22.1 凭什么你游戏我不能玩 220 22.2 紧耦合程序演化 221 22.3 合成/聚合复用原则 225 22.4 松耦合程序 226 22.5 桥接模式 229 22.6 桥接模式基本代码 231 22.7 我要开发“好”游戏 233 第23章 烤羊肉串引来思考——命令模式 234 23.1 吃烤羊肉串! 234 23.2 烧烤摊vs.烧烤店 235 23.3 紧耦合设计 236 23.4 松耦合设计 237 23.5 松耦合后 240 23.6 命令模式 242 23.7 命令模式作用 244 第24章 加薪非要老总批?——职责链模式 245 24.1 老板,我要加薪! 245 24.2 加薪代码初步 246 24.3 职责链模式 249 24.4 职责链好处 251 24.5 加薪代码重构 252 24.6 加薪成功 256 第25章 世界需要和平——中介者模式 257 25.1 世界需要和平! 257 25.2 中介者模式 258 25.3 安理会做中介 262 25.4 中介者模式优缺点 265 第26章 项目多也别傻做——享元模式 267 26.1 项目多也别傻做! 267 26.2 享元模式 269 26.3 网站共享代码 272 26.4 内部状态与外部状态 274 26.5 享元模式应用 277 第27章 其实你不懂老板心——解释器模式 279 27.1 其实你不懂老板心 279 27.2 解释器模式 280 27.3 解释器模式好处 282 27.4 音乐解释器 283 27.5 音乐解释器实现 284 27.6 料事如神 289 第28章 男人和女人——访问者模式 291 28.1 男人和女人! 291 28.2 最简单编程实现 292 28.3 简单面向对象实现 293 28.4 用了模式实现 295 28.5 访问者模式 300 28.6 访问者模式基本代码 301 28.7 比上不足,比下有余 304 第29章 OOTV杯超级模式大赛——模式总结 305 29.1 演讲任务 305 29.2 报名参赛 305 29.3 超模大赛开幕式 306 29.4 创建型模式比赛 309 29.5 结构型模式比赛 314 29.6 行为型模式一组比赛 321 29.7 行为型模式二组比赛 325 29.8 决赛 330 29.9 梦醒时分 333 29.10 没有结束结尾 334 附 录 A 培训实习生——面向对象基础 335 A.1 培训实习生 335 A.2 类与实例 335 A.3 构造方法 337 A.4 方法重载 338 A.5 属性与修饰符 340 A.6 封装 342 A.7 继承 343 A.8 多态 347 A.9 重构 350 A.10 抽象类 353 A.11 接口 354 A.12 集合 358 A.13 泛型 360 A.14 委托与事件 362 A.15 客套 366 附 录 B 参考文献 367
基本信息 原书名 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模式 4
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值