软件工程课件-11面向对象方法与技术_设计模式实践4
合集下载
软件工程 面向对象分析与设计PPT课件
面向过程
围绕功能，函数，数据公用，兼顾很多细节 系统规模大、数据多、操作烦杂，程序员难以应付 厂长，直接指挥每一个工人选用材料生产汽车
面向对象
面对的是一个个对象 实际上，每一组数据有特定的用途，一组操作调用一组数据，
将这组数据和操作代码，封装成一个对象，与外界相对隔离， 相对独立 厂长－车间1（发动机）车间2（轮胎）车间3（底盘）…… 类，对象，对象间接送消息，完成任务 降低难度，减少出错机会
面向对象分析的基本过程
面向对象分析法体现 在过程上的特点：不 强调活动的顺序，允 许各种活动的交替、 回溯进行
定义use case
发现对象
原
详
型 开
定义属性及服务
细 说
发
明
建立结构与连接
划分主题
建立交互图
1.23
© 2009 by Duym
Software Engineering
面向过程(po)与面向对象(OO)
利用自己已建立的类，或别人的放在类库中的类，缩短开 发周期
1.14
© 2009 by Duym
Software Engineering
2.5多态（polymorphism）
一班、二班、三班 铃声响了，走进不同的教室，上不同的课程
向不同的对象，发出相同的消息，执行不同的 操作
鼠标双击文件，exe文件则运行该文件，doc文件则运行 word打开该文档
对象模型是客观世界对象、属性以及对象彼 此间关系的抽象表达，描述了系统的静态结 构
表示方法
类与对象 结构与连接
一般特殊关系，分类关系，归纳关系，继承 整体部分关系，组成关系 实例连接，对象间属性之间的静态联系 消息连接，对象行为之间的动态联系
软件工程第十一章面向对象设计
THANKS
感谢观看
01
抽象类是一种不能被实例化的 类，它只能被其他类继承。
02
抽象类可以包含抽象方法和具 体方法。抽象方法是没有具体 实现的方法，需要在继承抽象 类的子类中实现。
03
通过继承抽象类，子类可以继 承抽象类的属性和方法，并且 可以重写或实现抽象类中的方 法。
接口与抽象类的选择
在设计软件时，选择使用接口还是抽象类取决于具体需求和设计目标。
关系
关系描述了对象之间的交互和联系。 常见的关系包括关联、聚合和继承。
继承与多态的设计
继承
继承是一种实现代码重用的方式，子类可以继承父类的属性和方法，并可以扩展或覆盖它们。通过继承，可以建 立类之间的层次结构，使得代码更加清晰和易于维护。
多态
多态是指一个接口可以有多种实现方式，或者一个对象可以有多种形态。多态可以提高代码的灵活性和可扩展性， 使得程序更加易于维护和修改。
02
类与对象的设计
类的定义与属性
类的定义
类是对象的抽象，它描述了一组具有相同属性和行为的对象。类定义了对象的结构、行为和关系。
属性
属性是类中用于描述对象状态的变量。每个对象都有其自己的属性值，这些属性值决定了对象的状态 。
对象的行为与关系
行为
行为是类中定义的方法，用于描述对 象可以执行的操作。方法定义了对象 的行为和功能。
高层模块不应该依赖于低层模块，它们都应 该依赖于抽象。
面向对象设计的优势
提高代码可重用性
通过类和继承实现代码重用，减少重 复代码。
提高代码可维护性
面向对象设计使得代码结构更加清晰， 易于理解和维护。
提高开发效率
通过快速原型开发，快速构建软件系 统。
软件设计与体系结构 第四章 面向对象的软件设计方法ppt课件
1精化软件架构2调整软件构成的类3精化交互模型4精化类之间关系在层次结构中较高层次的包可以依赖较低层次的包但应尽量在相邻的层次间发生如果针对某些子系统专门划分了接口包和实现包那么其他与该子系统相关的包吸能依赖于接口包不能依赖于实现包设计精化精化软件架构用户交互层包精化后的模型设计精化精化软件架构用户交互层中子包精化后的模型设计精化调整软件构成类若类的属性和操作简单但与其他类通信非常用频繁即耦合度很高这样的类可以合并到其他类中若一个类的属性可以区分为常用和罕用为提高效率拆分为常用类和数个罕用类建立聚合关系若一个类既要负责业务逻辑又要实现与外部数据通信那么可以拆分为业务逻辑类和通信类设计精化精化过程中新增加的类设计精化精化交互模型软件架构的组成类被迫调整之后对交互模型产生的影响新出现的对象可拆分后的对象如何参与交互过程在其中起到什么样的作用交互过程是否需要细化例如如增加必要的消息或对局部引用一个更加具体的交互图设计精化精化后的withdrawal顺序图根据软件复用的要求及软件结构简洁化清晰化的要求优化类之间的关系连接关系主要是构筑消息通道
l 设计的精化： u 对上面的逻辑、界面、数据模型等不同侧重点的设计结果进行整理，合并相似的类，保证各 模型之间的一到处性，并消除冗余，为了提高整全后模型的质量，可能需要引入继承、聚集 等关系对类设计进行组织和精化，并可能需要引入新的关键类和控制类。交互图等设计模型 进行精华，以更具体地描述场景交互过程。
些外部行为？ l 系统将通告参与者哪些事件？ .
用例的分析与设计 确定用例—确认参与者和责任
l 不同的参与者 u 系统管理员、程序员、会计、出纳员 u 与系统通信的其他系统
l 不同的责任 u 系统配置、程序设计、财务管理、现金管理
l 分析参与者的工作：使用案例 u 各种使用过程、步骤
l 设计的精化： u 对上面的逻辑、界面、数据模型等不同侧重点的设计结果进行整理，合并相似的类，保证各 模型之间的一到处性，并消除冗余，为了提高整全后模型的质量，可能需要引入继承、聚集 等关系对类设计进行组织和精化，并可能需要引入新的关键类和控制类。交互图等设计模型 进行精华，以更具体地描述场景交互过程。
些外部行为？ l 系统将通告参与者哪些事件？ .
用例的分析与设计 确定用例—确认参与者和责任
l 不同的参与者 u 系统管理员、程序员、会计、出纳员 u 与系统通信的其他系统
l 不同的责任 u 系统配置、程序设计、财务管理、现金管理
l 分析参与者的工作：使用案例 u 各种使用过程、步骤
《面向对象设计》PPT课件
一般来说，所有的继承都会引入编译时依赖 性。依赖性是可传递的，也就是说，如果C依赖 B，B依赖A，那么C也依赖A。
类及其依赖性
② 运行时继承依赖性
下图举例说明了在一棵继承树中涉及客户对象访问类服务的运行时 继承依赖性。图中类B的do1( )方法是从父类A继承来的，因此Test与 B没有运行时继承依赖性，只是一个静态依赖性，通过从Test到A的关 联来表明。如果在doTest方法中调用的是do2( )方法，或者在B中覆盖 了A的do1( )方法，则从Test到A和B就会存在运行时依赖性。
接口及其依赖性
2．实现依赖性
一个类可以实现多个接口，由类实现的接口集合称为该 类的供给接口。在UML2.0中，将一个类和该类实现的接口 之间的依赖性称为实现依赖性。
右图所示为实现依赖性的 UML符号，在箭头末端的类 实现了箭头所指向的接口。 从图中可以看到，Class1实 现了Interface1接口和 Interface2接口，而Class2 只实现了Interface2接口。
包及其依赖性
1. 包
包（package）又可称为层或子系统，是表示组织类的一 种方式，用于划分应用程序的逻辑模型。包是高度相关的类 的聚合，这些类本身是内聚的，但相对于其他聚合来说又是 松散耦合的。
包可以嵌套。外层包可以直接访问包括在它的嵌套包中的 任何类。包还可以导入其他包，例如，在包A中导入了包B， 这意味着包A或者包A的元素可以引用包B或者包B的元素。 因此，虽然一个类只属于一个包，但是它可以被导入其他包。 包的导入操作会引入包之间的依赖性以及它们的元素之间的 依赖性。
类及其依赖性
（2）无多态继承 使用继承最简单的方式是子类不覆盖从父类继承来的方法，
这样就不存在多态性继承问题。虽然无多态的继承有时并不 是十分有用，但理解和管理起来是最容易的。 （3）扩展继承和约束继承
类及其依赖性
② 运行时继承依赖性
下图举例说明了在一棵继承树中涉及客户对象访问类服务的运行时 继承依赖性。图中类B的do1( )方法是从父类A继承来的，因此Test与 B没有运行时继承依赖性，只是一个静态依赖性，通过从Test到A的关 联来表明。如果在doTest方法中调用的是do2( )方法，或者在B中覆盖 了A的do1( )方法，则从Test到A和B就会存在运行时依赖性。
接口及其依赖性
2．实现依赖性
一个类可以实现多个接口，由类实现的接口集合称为该 类的供给接口。在UML2.0中，将一个类和该类实现的接口 之间的依赖性称为实现依赖性。
右图所示为实现依赖性的 UML符号，在箭头末端的类 实现了箭头所指向的接口。 从图中可以看到，Class1实 现了Interface1接口和 Interface2接口，而Class2 只实现了Interface2接口。
包及其依赖性
1. 包
包（package）又可称为层或子系统，是表示组织类的一 种方式，用于划分应用程序的逻辑模型。包是高度相关的类 的聚合，这些类本身是内聚的，但相对于其他聚合来说又是 松散耦合的。
包可以嵌套。外层包可以直接访问包括在它的嵌套包中的 任何类。包还可以导入其他包，例如，在包A中导入了包B， 这意味着包A或者包A的元素可以引用包B或者包B的元素。 因此，虽然一个类只属于一个包，但是它可以被导入其他包。 包的导入操作会引入包之间的依赖性以及它们的元素之间的 依赖性。
类及其依赖性
（2）无多态继承 使用继承最简单的方式是子类不覆盖从父类继承来的方法，
这样就不存在多态性继承问题。虽然无多态的继承有时并不 是十分有用，但理解和管理起来是最容易的。 （3）扩展继承和约束继承
面向对象分析与设计原理及实践
面向对象分析与设计原理及实践面向对象程序设计（Object Oriented Programming, OOP）是目前程序设计领域中最为流行的一种设计方法，伴随着软件开发的日益复杂，我们需要高效的方法来管理和维护软件的复杂性。
在OOP中，一切皆为对象，对象是根据类定义而创建的。
类定义了一组属性和行为，对象是类的实例，拥有这些属性和行为。
使用面向对象的方式，可以更好地组织代码，提高代码重用和可维护性。
面向对象程序设计的三大特征面向对象程序设计的三大特征分别为封装、继承和多态。
封装是指将数据和行为打包到一个单元（class）中，通过访问权限限制来保证数据的安全性。
继承是指通过已有类派生出新的类，子类继承父类的所有属性和行为，同时可以添加自己的属性和行为，这种方式可以减少代码的重复性。
多态是指同一行为对于不同的对象具有不同的表现形式。
多态的实现方式有重载、重写和向上转型等。
面向对象分析与设计面向对象分析（Object Oriented Analysis, OOA）是一种软件工程方法，是软件设计中的第一步，它主要是从用户的需求出发，描述系统中的对象和他们之间的关系。
面向对象设计（Object Oriented Design, OOD）是软件设计的第二步，它主要是在OOA的基础上，根据系统需求，定义系统中的类以及类之间的关系。
在面向对象分析和设计中，主要有以下步骤：1. 需求收集和分析：通过与用户沟通，理解用户的需求，收集和分析需求。
2. 建立用例图和场景描述：从需求中抽取功能点，建立用例，同时描述用例的详细场景。
3. 建立类图：根据用例图和场景描述，建立类图，描述类之间的关系和属性。
4. 设计框架和结构：根据类图，设计系统的框架和结构。
5. 编写代码：在完成以上步骤后，编写代码实现系统。
面向对象实践在面向对象程序设计中，我们可以使用很多编程语言来实践，较为常见的有Java、C++、Python等。
在实践中，我们首先需要了解各种编程语言的特点和优势，根据需求选择合适的编程语言。
高级软件工程(第十一章) 面向对象设计方法PPT课件
➢在一个用例中，一个控制类应该同一个且仅一 个参与者相关联。
➢协调边界类和实体类之间的消息及消息发送的 顺序。
12
续
➢控制类作为完成用例任务的责任承担者，协调 、控制其他类共同完成用例规定的功能或行为 。对于比较复杂的用例，控制类通常并不处理 具体的任务细节，但是它应知道如何分解任务 ，如何将子任务分派给适当的辅助类，如何在 辅助类之间进行消息传递和协调。
② 开发交互图，即为每一个用例产生一个交互 图：其决定哪些对象一起工作，及怎样协同 工作。 (系统设计的核心)；
③ 根据开发交互图时得到的信息，迭代设计类 图和开发方法名称（确定类的行为和职责）
④ 用包图将设计类图分割成相关的功能。
3
用例的实现
➢称设计模型的最终开发结果为用例的实现。 ➢术语实现指的是对每个用例的详细系统过程进
16
导航可见性
➢一个对象可看到另一个对象并与之交互(导航 、可见性)。
➢一个对象可导航(发送消息)到另一个对象。 ➢一个对象通过发消息的方式和另一个对象进行
联系，那么第二个对象对于第一个对象来说必 须是可见的。 ➢对象具有能看见另一对象并与其交互的能力。
17
用例实现与交互图
➢用例的实现是在交互图的开发过程中完成的， 用例实现的过程就是确定哪些类通过发送消息 与其他类进行协作的过程。
➢设计时开发的交互图：顺序图或协作图。
18
对象职责
➢一种由对象负责实施系统过程的设计准则。 ➢集中确定一个系统必须支持的行为,再设计实
现这些行为的方法。通过这些行为,确定对象 职责。
19
用例控制器
➢每个用例含有许多来自外部参与者不同的消息。 ➢作为OO分析一部分的系统顺序图能够描述出这些
➢协调边界类和实体类之间的消息及消息发送的 顺序。
12
续
➢控制类作为完成用例任务的责任承担者，协调 、控制其他类共同完成用例规定的功能或行为 。对于比较复杂的用例，控制类通常并不处理 具体的任务细节，但是它应知道如何分解任务 ，如何将子任务分派给适当的辅助类，如何在 辅助类之间进行消息传递和协调。
② 开发交互图，即为每一个用例产生一个交互 图：其决定哪些对象一起工作，及怎样协同 工作。 (系统设计的核心)；
③ 根据开发交互图时得到的信息，迭代设计类 图和开发方法名称（确定类的行为和职责）
④ 用包图将设计类图分割成相关的功能。
3
用例的实现
➢称设计模型的最终开发结果为用例的实现。 ➢术语实现指的是对每个用例的详细系统过程进
16
导航可见性
➢一个对象可看到另一个对象并与之交互(导航 、可见性)。
➢一个对象可导航(发送消息)到另一个对象。 ➢一个对象通过发消息的方式和另一个对象进行
联系，那么第二个对象对于第一个对象来说必 须是可见的。 ➢对象具有能看见另一对象并与其交互的能力。
17
用例实现与交互图
➢用例的实现是在交互图的开发过程中完成的， 用例实现的过程就是确定哪些类通过发送消息 与其他类进行协作的过程。
➢设计时开发的交互图：顺序图或协作图。
18
对象职责
➢一种由对象负责实施系统过程的设计准则。 ➢集中确定一个系统必须支持的行为,再设计实
现这些行为的方法。通过这些行为,确定对象 职责。
19
用例控制器
➢每个用例含有许多来自外部参与者不同的消息。 ➢作为OO分析一部分的系统顺序图能够描述出这些
软件工程面向对象技术概述PPT教学课件
UML是一种定义良好，易于表达， 功能强大且普遍实用的建模语言。
UML的开发历程 UML2.0
UML 1.3 OMG采用,11/97 OMG修正,9/97 UML 1.1
OMG审核,1/97 UML 1.0
OMG认证
10/96 & 9/96 UML 0.9&0.91
UML同行 专家意见
10/95ຫໍສະໝຸດ UML 0.8同阶段。
UML的应用
UML是一种建模语言，不是一 种方法，它独立于过程。利于它建模 时，可遵循任何类型的建模过程。
UML的主要内容
（1）UML融合了Booch、OMT和OOSE方法 中的基本概念，而且这些基本概念与其他面向 对象技术中的基本概念大多相同;
（2）UML不仅仅是上述方法的简单汇合，而 是扩展了现有方法的应用范围;
(2) UML表示法
定义UML符号的表示法,为开发者或开发工 具使用这些图形符号和文本语法为系统建模提 供了标准。这些图形符号和文字所表达的是应 用级的模型,在语义上它是UML元模型的实例。
模型内容的组织和UML表述
UML的用于描述模型的基本词汇(“构造块”)：
• 事物(Things) • 关系(Relationships) • 图 (Diagrames)
• Booch方法 • Coad-Yourdon方法 • Rumbaugh 方法(简称OMT）
（Object Modeling Technology)
• Jacobson 方法（简称OOSE） • 由Rumbaugh 、 Booch 、 Jacobson
提出的统一建模语言 (Unify Modeing Language简称UML)
Booch’93 OMT-2
UML的开发历程 UML2.0
UML 1.3 OMG采用,11/97 OMG修正,9/97 UML 1.1
OMG审核,1/97 UML 1.0
OMG认证
10/96 & 9/96 UML 0.9&0.91
UML同行 专家意见
10/95ຫໍສະໝຸດ UML 0.8同阶段。
UML的应用
UML是一种建模语言，不是一 种方法，它独立于过程。利于它建模 时，可遵循任何类型的建模过程。
UML的主要内容
（1）UML融合了Booch、OMT和OOSE方法 中的基本概念，而且这些基本概念与其他面向 对象技术中的基本概念大多相同;
（2）UML不仅仅是上述方法的简单汇合，而 是扩展了现有方法的应用范围;
(2) UML表示法
定义UML符号的表示法,为开发者或开发工 具使用这些图形符号和文本语法为系统建模提 供了标准。这些图形符号和文字所表达的是应 用级的模型,在语义上它是UML元模型的实例。
模型内容的组织和UML表述
UML的用于描述模型的基本词汇(“构造块”)：
• 事物(Things) • 关系(Relationships) • 图 (Diagrames)
• Booch方法 • Coad-Yourdon方法 • Rumbaugh 方法(简称OMT）
（Object Modeling Technology)
• Jacobson 方法（简称OOSE） • 由Rumbaugh 、 Booch 、 Jacobson
提出的统一建模语言 (Unify Modeing Language简称UML)
Booch’93 OMT-2
《软件工程》PPT课件
设计方法
E-R图、范式化、反范式化等
优化策略
索引优化、查询优化、存储优化等
04
软件测试与质量保证
测试策略与计划制定
确定测试目标
明确测试的目的和范围，确保测试工作有针对 性。
制定测试计划
根据测试目标，制定详细的测试计划，包括测 试资源、时间表、风险管理等。
选择测试方法
根据软件特点和测试需求，选择合适的测试方法，如黑盒测试、白盒测试、灰 盒测试等。
《软件工程》PPT课件
目录
• 引言 • 软件需求分析 • 软件设计与开发 • 软件测试与质量保证 • 软件维护与演化 • 软件工程管理与实践
01
引言
软件工程概述
软件工程定义
软件工程是一门研究计算机软件开发、 维护和管理的科学，旨在通过系统方 法、工具和技术来提高软件开发的效 率和质量。
软件工程的目标
B
C
D
持续改进与优化
在项目执行过程中，不断总结经验教训， 持续改进和优化项目管理流程和方法。
迭代开发与交付
通过短周期的迭代开发和交付，不断收集 用户反馈，及时调整产品方向和开发计划。
THANKS
感谢观看
回归测试
02
03
缺陷分析
在修复缺陷后，进行回归测试以 验证修复效果，确保软件质量得 到提升。
对缺陷进行统计分析，找出缺陷 产生的原因和规律，为改进软件 开发过程提供依据。
质量保证措施
代码审查 通过代码审查，检查代码是否符合编码
规范和设计要求，提高代码质量。
质量度量与监控 建立质量度量体系，对软件质量进行 度量和监控，及时发现和解决问题。
在给定成本和时间内，设计、实现和 维护软件系统。同时，软件工程也致 力于开发高质量、高可靠性和易于维 护的软件产品。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
定义所有visitor的接口。
共124页 第13页
结构
共124页 第14页
visitor(访问者）模式
参与者：
Visitor（访问者，如NodeVisitor） — 为该对象结构中ConcreteElement的每一个类声明
一个Visit操作。 ConcreteVisitor（具体访问者，如：
共124页 第8页
visitor(访问者）模式
使用Visitor模式的编译器： 若要对一个过程进行类型检查，那么它将会创
建一个TypeCheckingVisitor对象，并以这个对象为 一个参数在抽象语法树上调用Accept操作。每一个 结点在实现Accept时将会回调访问者：一个赋值结 点调用访问者的VisitAssignment操作，而一个变量 引用将调用VisitVariableReference。
象语法树。该编译器需在抽象语法树上实施某些
操作以进行“静态语义”分析，例如检查是否所 有
的变量都已经被定义了。它也需要生成代码。因
此它可能要定义许多操作以进行类型检查、代码
优化、流程分析，检查变量是否在使用前被赋初
值，等等。
共124页 第4页
visitor(访问者）模式
这些操作大多要求对不同的节点进行不同的处 理。例如对代表赋值语句的结点的处理就不同于对 代表变量或算术表达式的结点的处理。因此有用于 赋值语句的类，有用于变量访问的类，还有用于算 术表达式的类，等等。结点类的集合当然依赖于被 编译的语言，但对于一个给定的语言其变化不大。
使用visitor模式，必须定义两个类层次：一个 对应于接受操作的元素（ Node层次）另一个对 应于定义对元素的操作的访问者（ NodeVisitor层
次）。给访问者类层次增加一个新的子类即可创建 一个新的操作。只要该编译器接受的语法不改变即 不需要增加新的Node子类），我们就可以简单
的定义新的NodeVisitor子类以增加新的功能。
以前类AssignmentNode 的TypeCheck操作现在 成为TypeCheckingVisitor的VisitAssignment操作。
共124页 第9页
visitor(访问者）模式
共124页 第10页
visitor(访问者）模式
共124页 第11页
visitor(访问者）模式
visitor模式将每一个编译步骤的操作封装在 一个与该步骤相关的visitor中。
TypeCheckingVisitor） — 实现每个由Visitor声明的操作。 Element（元素，如Node） — 定义一个Accept操作，它以一个访问者为参数。
共124页 第15页
visitor(访问者）模式
ConcreteElement（具体元素，如： AssignmentNode，VariableRefNode）
— 实现Accept操作，该操作以一个访问者为参数。 ObjectStructure（对象结构，如Program） — 能枚举它的元素。 — 可以提供一个高层的接口以允许该访问者访问它
的元素。 — 可以是一个复合（或是一个集合，如一个列表或
一个无序集合。
共124页 第16页
visitor(访问者）模式共1Fra bibliotek4页 第18页
visitor(访问者）模式
效果 1) 访问者模式使得易于增加新的操作 2) 访问者集中相关的操作而分离无关的操作 3) 增加新的ConcreteElement类很困难 4) 通过类层次进行访问 5) 破坏封装
共124页 第7页
visitor(访问者）模式
实现上述两个目标，可以将每一个类中相关的 操作包装在一个独立的对象（称为一个Visitor）中， 并在遍历抽象语法树时将此对象传递给当前访问的元 素。当一个元素“接受”该访问者时，该元素向访问
者 发送一个包含自身类信息的请求。该请求同时也将该 元素本身作为一个参数。然后访问者将为该元素执行 该操作—这一操作以前是在该元素的类中的。
共124页 第12页
visitor(访问者）模式
适用性:
➢ 一个对象结构包含许多对象类，我们想执行一些 依赖于其具体类的操作。
➢ 要对一个对象结构中的对象进行很多不同的并 且不相关的操作，又不想改变这些对象类。
➢ 定义对象结构的类很少改变，但经常需要在此结 构上定义新的操作。改变对象结构类，需要重新
共124页 第2页
visitor(访问者）模式
意图： ➢ 表示一个作用于某对象结构中的各元素的
操作，将更新封装到一个类中（访问操 作），并由待更改类提供一个接收接口 。 ➢ 它使你可以在不改变各元素的类的前提下 定义作用于这些元素的新操作。
共124页 第3页
visitor(访问者）模式
动机：
考虑一个编译器，它将源程序表示为一个抽
共124页 第5页
visitor(访问者）模式
共124页 第6页
visitor(访问者）模式
存在的问题：
将所有这些操作分散到各种结点类中会导致整 个系统难以理解、难以维护和修改。此外，增加新 的操作通常需要重新编译所有这些类。
如果可以独立地增加新的操作，并且使这些结 点类独立于作用于其上的操作，将会更好一些。
协作：
一个使用Visitor模式的客户必须创建一个 ConcreteVisitor对象，然后遍历该对象结构，并 用该访问者访问每一个元素。当一个元素被访问时， 它调用对应于它的类的Visitor操作。如果必要， 该元素将自身作为这个操作的一个参数以便该访问 者访问它的状态。
共124页 第17页
下面的交互框图说明了一个对象结构、 一个访问者和两个元素之间的协作。
面向对象的技术与方法
北京理工大学计算机系 宋红
visitor(访问者）模式
问题：
在面向对象系统的开发和设计过程，经常会遇到一种情 况就是需求变更（RequirementChanging），经常我们做 好的一个设计、实现了一个系统原型，咱们的客户又会有了 新的需求。我们又因此不得不去修改已有的设计，最常见就 是解决方案就是给已经设计、实现好的类添加新的方法去实 现客户新的需求，这样就陷入了设计变更的梦魇：不停地打 补丁，其带来的后果就是设计根本就不可能封闭、编译永远 都是整个系统代码。
共124页 第13页
结构
共124页 第14页
visitor(访问者）模式
参与者：
Visitor（访问者，如NodeVisitor） — 为该对象结构中ConcreteElement的每一个类声明
一个Visit操作。 ConcreteVisitor（具体访问者，如：
共124页 第8页
visitor(访问者）模式
使用Visitor模式的编译器： 若要对一个过程进行类型检查，那么它将会创
建一个TypeCheckingVisitor对象，并以这个对象为 一个参数在抽象语法树上调用Accept操作。每一个 结点在实现Accept时将会回调访问者：一个赋值结 点调用访问者的VisitAssignment操作，而一个变量 引用将调用VisitVariableReference。
象语法树。该编译器需在抽象语法树上实施某些
操作以进行“静态语义”分析，例如检查是否所 有
的变量都已经被定义了。它也需要生成代码。因
此它可能要定义许多操作以进行类型检查、代码
优化、流程分析，检查变量是否在使用前被赋初
值，等等。
共124页 第4页
visitor(访问者）模式
这些操作大多要求对不同的节点进行不同的处 理。例如对代表赋值语句的结点的处理就不同于对 代表变量或算术表达式的结点的处理。因此有用于 赋值语句的类，有用于变量访问的类，还有用于算 术表达式的类，等等。结点类的集合当然依赖于被 编译的语言，但对于一个给定的语言其变化不大。
使用visitor模式，必须定义两个类层次：一个 对应于接受操作的元素（ Node层次）另一个对 应于定义对元素的操作的访问者（ NodeVisitor层
次）。给访问者类层次增加一个新的子类即可创建 一个新的操作。只要该编译器接受的语法不改变即 不需要增加新的Node子类），我们就可以简单
的定义新的NodeVisitor子类以增加新的功能。
以前类AssignmentNode 的TypeCheck操作现在 成为TypeCheckingVisitor的VisitAssignment操作。
共124页 第9页
visitor(访问者）模式
共124页 第10页
visitor(访问者）模式
共124页 第11页
visitor(访问者）模式
visitor模式将每一个编译步骤的操作封装在 一个与该步骤相关的visitor中。
TypeCheckingVisitor） — 实现每个由Visitor声明的操作。 Element（元素，如Node） — 定义一个Accept操作，它以一个访问者为参数。
共124页 第15页
visitor(访问者）模式
ConcreteElement（具体元素，如： AssignmentNode，VariableRefNode）
— 实现Accept操作，该操作以一个访问者为参数。 ObjectStructure（对象结构，如Program） — 能枚举它的元素。 — 可以提供一个高层的接口以允许该访问者访问它
的元素。 — 可以是一个复合（或是一个集合，如一个列表或
一个无序集合。
共124页 第16页
visitor(访问者）模式共1Fra bibliotek4页 第18页
visitor(访问者）模式
效果 1) 访问者模式使得易于增加新的操作 2) 访问者集中相关的操作而分离无关的操作 3) 增加新的ConcreteElement类很困难 4) 通过类层次进行访问 5) 破坏封装
共124页 第7页
visitor(访问者）模式
实现上述两个目标，可以将每一个类中相关的 操作包装在一个独立的对象（称为一个Visitor）中， 并在遍历抽象语法树时将此对象传递给当前访问的元 素。当一个元素“接受”该访问者时，该元素向访问
者 发送一个包含自身类信息的请求。该请求同时也将该 元素本身作为一个参数。然后访问者将为该元素执行 该操作—这一操作以前是在该元素的类中的。
共124页 第12页
visitor(访问者）模式
适用性:
➢ 一个对象结构包含许多对象类，我们想执行一些 依赖于其具体类的操作。
➢ 要对一个对象结构中的对象进行很多不同的并 且不相关的操作，又不想改变这些对象类。
➢ 定义对象结构的类很少改变，但经常需要在此结 构上定义新的操作。改变对象结构类，需要重新
共124页 第2页
visitor(访问者）模式
意图： ➢ 表示一个作用于某对象结构中的各元素的
操作，将更新封装到一个类中（访问操 作），并由待更改类提供一个接收接口 。 ➢ 它使你可以在不改变各元素的类的前提下 定义作用于这些元素的新操作。
共124页 第3页
visitor(访问者）模式
动机：
考虑一个编译器，它将源程序表示为一个抽
共124页 第5页
visitor(访问者）模式
共124页 第6页
visitor(访问者）模式
存在的问题：
将所有这些操作分散到各种结点类中会导致整 个系统难以理解、难以维护和修改。此外，增加新 的操作通常需要重新编译所有这些类。
如果可以独立地增加新的操作，并且使这些结 点类独立于作用于其上的操作，将会更好一些。
协作：
一个使用Visitor模式的客户必须创建一个 ConcreteVisitor对象，然后遍历该对象结构，并 用该访问者访问每一个元素。当一个元素被访问时， 它调用对应于它的类的Visitor操作。如果必要， 该元素将自身作为这个操作的一个参数以便该访问 者访问它的状态。
共124页 第17页
下面的交互框图说明了一个对象结构、 一个访问者和两个元素之间的协作。
面向对象的技术与方法
北京理工大学计算机系 宋红
visitor(访问者）模式
问题：
在面向对象系统的开发和设计过程，经常会遇到一种情 况就是需求变更（RequirementChanging），经常我们做 好的一个设计、实现了一个系统原型，咱们的客户又会有了 新的需求。我们又因此不得不去修改已有的设计，最常见就 是解决方案就是给已经设计、实现好的类添加新的方法去实 现客户新的需求，这样就陷入了设计变更的梦魇：不停地打 补丁，其带来的后果就是设计根本就不可能封闭、编译永远 都是整个系统代码。