论面向对象方法与软件复用关系

论面向对象方法与软件复用关系

尹志喜

(本文转载自软件工程专家网www.21cmm.com

1.软件复用的特点和现状

  软件复用就是将已有的软件成分用于构造新的软件系统。可以被复用的软件成分一般称作可复用构件,无论对可复用构件原封不动地使用还是作适当的修改后再使用,只要是用来构造新软件,则都可称作复用。软件复用不仅仅是对程序的复用,它还包括对软件生产过程中任何活动所产生的制成品的复用,如项目计划、可行性报告、需求定义、分析模型、设计模型、详细说明、源程序、测试用例等等。如果是在一个系统中多次使用一个相同的软件成分,则不称作复用,而称作共享;对一个软件进行修改,使它运行于新的软硬件平台也不称作复用,而称作软件移值。
目前及近期的未来最有可能产生显著效益的复用是对软件生命周期中一些主要开发阶段的软件制品的复用,按抽象程度的高低,可以划分为如下的复用级别:

(1)代码的复用

  包括目标代码和源代码的复用。其中目标代码的复用级别最低,历史也最久,当前大部分编程语言的运行支持系统都提供了连接(Link)、绑定(Binding)等功能来支持这种复用。源代码的复用级别略高于目标代码的复用,程序员在编程时把一些想复用的代码段复制到自己的程序中,但这样往往会产生一些新旧代码不匹配的错误。想大规模的实现源程序的复用只有依靠含有大量可复用构件的构件库。如”对象链接及嵌入”(OLE)技术,既支持在源程序级定义构件并用以构造新的系统,又使这些构件在目标代码的级别上仍然是一些独立的可复用构件,能够在运行时被灵活的得新组合为各种不同的应用。

(2)设计的复用

  设计结果比源程序的抽象级别更高,因此它的复用受实现环境的影响较少,从而使可复用构件被复用的机会更多,并且所需的修改更少。这种复用有三种途径,第一种途径是从现有系统的设计结果中提取一些可复用的设计构件,并把这些构件应用于新系统的设计;第二种途径是把一个现有系统的全部设计文档在新的软硬件平台上重新实现,也就是把一个设计运用于多个具体的实现;第三种途径是独立于任何具体的应用,有计划地开发一些可复用的设计构件。

(3)分析的复用

  这是比设计结果更高级别的复用,可复用的分析构件是针对问题域的某些事物或某些问题的抽象程度更高的解法,受设计技术及实现条件的影响很少,所以可复用的机会更大。复用的途径也有三种,即从现有系统的分析结果中提取可复用构件用于新系统的分析;用一份完整的分析文档作输入产生针对不同软硬件平台和其它实现条件的多项设计;独立于具体应用,专门开发一些可复用的分析构件。

(4)测试信息的复用

  主要包括测试用例的复用和测试过程信息的复用。前者是把一个软件的测试用例在新的软件测试中使用,或者在软件作出修改时在新的一轮测试中使用。后者是在测试过程中通过软件工具自动地记录测试的过程信息,包括测试员的每一个操作、输入参数、测试用例及运行环境等一切信息。这种复用的级别,不便和分析、设计、编程的复用级别作准确的比较,因为被复用的不是同一事物的不同抽象层次,而是另一种信息,但从这些信息的形态看,大体处于与程序代码相当的级别。

  由于软件生产过程主要是正向过程,即大部分软件的生产过程是使软件产品从抽象级别较高的形态向抽象级别较低的形态演化,所以较高级别的复用容易带动较低级别的复用,因而复用的级别越高,可得到的回报也越大,因此分析结果和设计结果在目前很受重视。用户可购买生产商的分析件和设计件,自己设计或编程,掌握系统的剪裁、扩充、维护、演化等活动。

2.软件复用的根本因难

  软件复用各方面的困难,无论是技术问题还是非技术问题,都影响着软件复用的广泛实行。

(1)技术因素。

  构件与应用系统之间的差异。一些开发者开发的构件,要做到在被另一些人开发的系统中使用时正好合适,从内容到对外接口都恰好相符,或者作很少的修改,这不是一件简单的事;构件要达到一定的数量,才能支持有效的复用,而大量构件的获得需要有很高的投入和长期的积累;发现合用构件的困难,当构件达到较大的数量时,使用者要从中找到一个自己想要的构件,并断定它确实是自己需要的,不是一件轻而易举的事;基于复用的软件开发方法和软件过程是一个新的研究实践领域,需要一些新的理论、技术及支持环境,目前这方面的研究成果和实践经验都不够充分。

(2)人的因素。

  软件开发是一种创造性工作,长期从事这个行业的人们形成了一种职业习惯:喜欢自己创造而不喜欢使用别人的东西,特别是当要对别人开发的软件作一些修改再使用时,他们常常喜欢自己另写一个。

(3)管理因素

  在软件生产的管理中,从以往沿习了一些与复用的目标很不协调的制度与政策,如计算工作量时,对复用的部分打很大的折扣,甚至不算工作量;另外,不是在项目开始时自觉地向着造就可复用构件的方向努力,而是在它完成之后,看看是否能从中找到一些可复用构件。这些弊端妨碍了复用水平的提高和复用规模的扩大,甚至会挫伤致力于复用的人员的积极性。

(4)教育因素

  在软件科学技术的教育与培训中,缺乏关于软件复用的内容,很少有这方面的专门教材及课程,即使在其它教材及课程中提到软件复用,其篇幅及内容也相当薄弱。

(5)法律因素

  在法律上还存在一些问题,例如,一个可复用构件在某个应用系统中出现了错误,而构件的开发者和应用系统的开发者不是一个厂商,那么责任应该由谁负?此外,在版权、政府政策等方面也存在一些悬而未决的问题。
另外,软件产品是一种精神产品,它的产生几乎完全是人脑思维的结果,它的价值,也几乎完全在于其中所凝结的思想;它的物质载体的制造过程与价值含量都是微不足道的。物质产品的生产受到人类制造能力的限制,现有的一却物质产品的复杂性都没有超过这种限度,软件却没有这种限制,只要人的大脑能想到的问题,都可能要求软件去解决,人脑所能思考的问题的复杂性,远远超出了人类能制造的物质产品的复杂性,因而使软件的复用更为困难。

3. OO方法对软件复用的支持

  支持软件复用是人们对面向对象方法寄托的主要希望之一,也是这种方法受到广泛重视的主要原因之一。面向对象方法之所以特别有利于软件复用,是由于它的主要概念及原则与软件复用的要求十分吻合。

  面向对象方法从面向对象的编程发展到面向对象的分析与设计,使这种方法支持软件复用的固有特征能够从软件生命周期的前期阶段开始发挥作用,从而使OO方法对软件复用的支持达到了较高的级别。与其它软件工程方法相比,面向对象方法的一个重要优点是,它可以在整个软件生命周期达到概念、原则、术语及表示法的高度一致。这种一致性使得各个系统成分尽管在不同的开发与演化阶段有不同的形态,但可具有贯穿整个软件生命周期的良好映射。这一优点使OO方法不但能在各个级别支持软件复用,而且能对各个级别的复用形成统一的、高效的支持,达到良好的全局效果。做到这一点的必要条件是,从面向对象软件开发的前期阶段---OOA就把支持软件复用作为一个重点问题来考虑。运用OOA方法所定义的对象类具有适合作为可复用构件的许多特征,OOA结果对问题域的良好映射,使同类系统的开发者容易从问题出发,在已有的OOA结果中发现不同粒度的可复用构件。

(1)OOA模型

  OOA方法建立的系统模型分为基本模型(类图)和补充模型(主题图与交互图),强调在OOA基本模型中只表示最重要的系统建模信息,较为细节的信息则在详细说明中结出。这种表示策略使OOA基本模型体现了更高的抽象,更容易成为一个可复用的系统构架。当这个构架在不同的应用系统中复用时,在很多情况下可通过不同的详细说明体现系统之间的差异,因此对系统构件的改动较少。

(2)OOA与OOD的分工

  OOA只注重与问题域及系统责任有关的信息,OOD考虑与实现条件有关的因素。这种分工使OOA模型独立于具体的实现条件,从而使分析结果可以在问题域及系统责任相同而实现条件互异的多个系统中复用,并为从同一领域的多个系统的分析模型提炼领域模型创造了有利条件。

(3) 对象的表示

  所有的对象都用类作为其抽象描述。对象的一却信息,包括对象的属性、行为及其对外关系等等都是通过对象类来表示的。类作为一种可复用构件,在运用于不同系统时,不会出现因该类对象实例不同而使系统模型有所不同的情况。

(4) 一般-特殊结构

  引入对一般-特殊结构中多态性的表示法,从而增强了类的可复用性。通过对多态性的表示,使一个类可以在需求相似而未必完全相同的系统中被复用。

(5)整体-部分结构

  把部分类作为可复用构件在整个类中使用,这种策略的原理与在特殊类中使用一般类是一致的,但在某些情况下,对问题域的映射比通过继承实现复用显得更为自然。另外还可通过整体-部分结构支持领域复用的策略---从整体对象中分离出一组可在领域范围内复用的属性与服务,定义为部分对象,使之成为领域复用构件。

(6)实例连接

  建议用简单的二元关系表示各种复杂关系和多元关系。这一策略使构成系统的基本成分(对象类)以及它们之间的关系在表示形式和实现技术上都是规范和一致的这种规范性和一致性对于可复用构件的组织、管理和使用,都是很有益的。

(7)类描述模板

  作为OOA详细说明主要成分的类描述模板,对于对象之间关系的描述注意到使用者与被使用者的区别,仅在使用者一端给出类之间关系的描述信息。这说明可复用构件之间的依赖关系不是对等的。因此,在继承、聚合、实例连接及消息连接等关系的使用者一端描述这些关系,有利于这些关系信息和由它们指出的被依赖成份的同时复用。在被用者一端不描述这些关系,则避免了因复用场合的不同所引起的修改。

(8)使用CASE

  由于使用CASE是对用户需求的一种规范化描述,因此它比普通形式的需求文档具有更强的可复用性。每个使用case 是对一个活动者使用系统的一项功能时的交互活动所进行描述,它具有完整性和一定的独立性,因此很适于作为可复用构件。

4. 复用技术对OO方法的支持

  面向对象的软件开发和软件复用之间的关系是相辅相成的。一方面,OO方法的基本概念、原则与技术提供了实现软件复用的有利条件;另一方面,软件复用技术也对面向对象的软件开发提供了有力的支持。

(1)类库

  在面向对象的软件开发中,类库是实现对象类复用的基本条件。人们己经开发了许多基于各种OOPL的编程类库,有力地支持了源程序级的软件复用,但要在更高的级别上实现软件复用,仅有编程类库是不够的。实现OOA结果和OOD结果的复用,必须有分析类库和设计类库的支持。为了更好地支持多个级别的软件复用,可以在OOA类库、OOD类库和OOP类库之间建立各个类在不同开发阶段的对应与演化关系。即建立一种线索,表明每个OOA的类对应着哪个(或哪些)OOD类,以及每个OOD类对应着各种OO编程语言类库中的哪个OOP类。

(2) 构件库

  类库可以看作一种特殊的可复用构件库,它为在面向对象的软件开发中实现软件复用提供了一种基本的支持。但类库只能存储和管理以类为单位的可复用构件,不能保存其它形式的构件;但是它可以更多地保持类构件之间的结构与连接关系。构件库中的可复用构件,既可以是类,也可以是其它系统单位;其组织方式,可以不考虑对象类特有的各种关系,只按一般的构件描述、分类及检索方法进行组织。在面向对象的软件开发中,可以提炼比对象类粒度更大的可复用构件,例如把某些结构或某些主题作为可复用构件;也可以提炼其它形式的构件,例如use case 或交互图。这些构件库中,构件的形式及内容比类库更丰富,可为面向对象的软件开发担供更强的支持。

(3)构架库

  如果在某个应用领域中已经运用OOA技术建立过一个或几个系统的OOA模型,则每个OOA模型都应该保存起来,为该领域新系统的开发提供参考。当一个领域已有多个OOA模型时,可以通过进一步抽象而产生一个可复用的软件构架。形成这种可复用软件构架的更正规的途径是开展领域分析。通过正规的领域分析获得的软件构架将更准确地反映一个领域中各个应用系统的共性,具有更强的可复用价值。

(4)工具

  有效的实行软件复用需要有一些支持复用的软件工具,包括类库或构件/构架库的管理、维护与浏览工具,构件提取及描述工具,以及构件检索工具等等。以复用支持为背景的OOA工具和OOD工具在设计上也有相应的要求,工具对OOA/OOD过程的支持功能应包括:从类库或构件/构架库中寻找可复用构件;对构件进行修改,并加入当前的系统模型;把当前系统开发中新定义的类(或其它构件)提交到类库(或构件库)。

(5)OOA过程

  在复用技术支持下的OOA过程,可以按两种策略进行组织。第一种策略是,基本保持某种OOA方法所建议的OOA过程原貌,在此基础上对其中的各个活动引入复用技术的支持;另一种策略是重新组织OOA过程。

  第一种策略是在原有的OOA过程基础上增加复用技术的支持,应补充说明的一点是,复用技术支持下的OOA过程应增加一个提交新构件的活动。即在一个具体应用系统的开发中,如果定义了一些有希望被其它系统复用的构件,则应该把它提交到可复用构件库中。第二种策略的前提是:在对一个系统进行面向对象的分析之前,己经用面向对象方法对该系统所属的领域进行过领域分析,得到了一个用面向对象方法表示的领域构架和一批类构件,并且具有构件/构架库、类库及相应工具的支持。在这种条件下,重新考虑OOA过程中各个活动的内容及活动之间的关系,力求以组装的方式产生OOA模型,将使OOA过程更为合理,并达到更高的开发效率。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

基本信息 原书名: Design Patterns:Elements of Reusable Object-Oriented software 原出版社: Addison Wesley/Pearson 作者: (美)Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides [作译者介绍] 译者: 李英军 马晓星 蔡敏 刘建中 丛书名: 计算机科学丛书 出版社:机械工业出版社 ISBN:7111075757 上架时间: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
相关推荐
本书并不是一本介绍面向对象技术或设计的书,目前已有不少好书介绍面向对象技术或设计。本书假设你至少已经比较熟悉一种面向对象编程语言,并且有一定的面向对象设计经验。当我们提及“类型”和“多态”,或“接口”继承“实现”继承的关系时,你应该对这些概念了然于胸,而不必迫不及待地翻阅手头的字典。 另外,这也不是一篇高级专题技术文,而是一本关于设计模式的书,它描述了在面向对象软件设计过程中针对特定问题的简洁而优雅的解决方案。设计模式捕获了随时间进化发展的问题的求解方法,因此它们并不是人们从一开始就采用的设计方案。它们反映了不为人知的重新设计和重新编码的成果,而这些都来自软件开发者为了设计出灵活可复用软件而长时间进行的艰苦努力。设计模式捕获了这些解决方案,并用简洁易用的方式表达出来。 设计模式并不要求使用独特的语言特性,也不采用那些足以使你的朋友或老板大吃一惊的神奇的编程技巧。所有的模式均可以用标准的面向对象语言实现,这也许有时会比特殊的解法多费一些功夫,但是为了增加软件的灵活性和可复用性,多做些工作是值得的。 一旦你理解了设计模式并且有了一种“Aha!”(而不是“Huh?”)的应用经验和体验后,你将用一种非同寻常的方式思考面向对象设计。你将拥有一种深刻的洞察力,以帮助你设计出更加灵活的、模块化的、可复用的和易理解的软件—这也是你为何着迷于面向对象技术的源动力,不是吗? 当然还有一些提示和鼓励:第一次阅读此书时你可能不会完全理解它,但不必着急,我们在起初编写这本书时也没有完全理解它们!请记住,这不是一本读完一遍就可以束之高阁的书。我们希望你在软件设计过程中反复参阅此书,以获取设计灵感。 我们并不认为这组设计模式是完整的和一成不变的,它只是我们目前对设计的思考的记录。因此我们欢迎广大读者的批评指正,无从书中采用的实例、参考,还是我们遗漏的已知应用,或应该包含的设计模式等方面。你可以通过Addison-Wesley写信给我们,或发送电子邮件到:design-patterns@cs.uiuc.edu。你还可以发送邮件“send design pattern source”到design-patterns-source@cs.uiuc.edu获取书中的示例代码部分的源代码。 另外我们有一个专门的网页报道最新的消息更新:
本书并不是一本介绍面向对象技术或设计的书,目前已有不少好书介绍面向对象技术或设计。本书假设你至少已经比较熟悉一种面向对象编程语言,并且有一定的面向对象设计经验。当我们提及“类型”和“多态”,或“接口”继承“实现”继承的关系时,你应该对这些概念了然于胸,而不必迫不及待地翻阅手头的字典。 另外,这也不是一篇高级专题技术文,而是一本关于设计模式的书,它描述了在面向对象软件设计过程中针对特定问题的简洁而优雅的解决方案。设计模式捕获了随时间进化发展的问题的求解方法,因此它们并不是人们从一开始就采用的设计方案。它们反映了不为人知的重新设计和重新编码的成果,而这些都来自软件开发者为了设计出灵活可复用软件而长时间进行的艰苦努力。设计模式捕获了这些解决方案,并用简洁易用的方式表达出来。 设计模式并不要求使用独特的语言特性,也不采用那些足以使你的朋友或老板大吃一惊的神奇的编程技巧。所有的模式均可以用标准的面向对象语言实现,这也许有时会比特殊的解法多费一些功夫,但是为了增加软件的灵活性和可复用性,多做些工作是值得的。 一旦你理解了设计模式并且有了一种“Aha!”(而不是“Huh?”)的应用经验和体验后,你将用一种非同寻常的方式思考面向对象设计。你将拥有一种深刻的洞察力,以帮助你设计出更加灵活的、模块化的、可复用的和易理解的软件—这也是你为何着迷于面向对象技术的源动力,不是吗? 当然还有一些提示和鼓励:第一次阅读此书时你可能不会完全理解它,但不必着急,我们在起初编写这本书时也没有完全理解它们!请记住,这不是一本读完一遍就可以束之高阁的书。我们希望你在软件设计过程中反复参阅此书,以获取设计灵感。 目 录 序言 前言 读者指南 第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 AdapterBridge 144 4.8.2 Composite、DecoratorProxy 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
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值