面向对象分析和设计（设计模式）

面向对象分析与设计重点归纳

第一章

1.1.2 UML结构（视图，图，模型元素，通用机制）

视图

(1)用户视图：以用户的观点表示系统的目标，它是所有视图的核心，该视图描述系统的需求。

(2)结构视图：表示系统的静态行为，描述系统的静态元素，如包、类与对象，以及它们之间的关系。

(3)行为视图：表示系统的动态行为，描述系统的组成元素（如对象）在系统运行时的交互关系。

(4)实现视图：表示系统中逻辑元素的分布，描述系统中物理文件以及它们之间的关系。

(5)环境视图：表示系统中物理元素的分布，描述系统中硬件设备以及它们之间的关系。

图

图与视图对应关系记着常用的三个即可，用例图—用户视图，类图—结构试图，顺序图—行为试图

(1)用例图(UseCaseDiagram)：又称为用况图，对应于用户视图。在用例图中，使用用例来表示系统的功能需求，用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。用例图与用例说明文档(UseCaseSpecification)是常用的需求建模工具，也称为用例建模。
(2)类图(ClassDiagram)：对应于结构视图。类图使用类来描述系统的静态结构，类图包含类和它们之间的关系，它描述系统内所声明的类，但没有描述系统运行时类的行为。在本章1.2节将学习类图。
用例图与类图是UML13种图中使用频率最高的两种图。
(3)对象图(ObjectDiagram)：对应于结构视图。对象图是类图在某一时刻的一个实例，用于表示类的对象实例之间的关系。
(4)包图(PackageDiagram)：UML2.0的新增图，对应于结构视图。包图用于描述包与包之间的关系，包是一种把元素组织到一起的通用机制，例如可以将多个类组织成一个包。
(5)组合结构图(CompositeStructureDiagram)：UML2.0的新增图，对应于结构视图。组合结构图将每一个类放在一个整体中，从类的内部结构来审视一个类。组合结构图可用于表示一个类的内部结构，用于描述一些包含复杂成员或内部类的类结构。
(6)状态图(StateDiagram)：对应于行为视图。状态图用来描述一个特定对象的所有可能状态及其引起状态转移的事件。一个状态图包括一系列对象的状态及状态之间的转换。在本章1.4节将学习状态图。
(7)活动图(ActivityDiagram)：对应于行为视图。活动图用来表示系统中各种活动的次序，它的应用非常广泛，既可用来描述用例的工作流程，也可以用来描述类中某个方法的操作行为。
(8)顺序图(SequenceDiagram)：又称为时序图或序列图，对应于行为视图。顺序图用于表示对象之间的交互，重点表示对象之间发送消息的时间顺序。在本章1.3节将学习顺序图。
(9)通信图(CommunicationDiagram)：在UML1.x中称为协作图，对应于行为视图。通信图展示了一组对象、这些对象间的连接以及它们之间收发的消息。它与顺序图是同构图，也就是它们包含了相同的信息，只是表达方式不同而已，通信图与顺序图可以相互
转换。
(10)定时图(TimingDiagram)：UML2.0的新增图，对应于行为视图。定时图采用一种带数字刻度的时间轴来精确地描述消息的顺序，而不是像顺序图那样只是指定消息的相对顺序，而且它还允许可视化地表示每条生命线的状态变化，当需要对实时事件进行定义时，定时图可以很好地满足要求。
(11)交互概览图(InteractionOverviewDiagram)：UML2.0新增图，对应于行为视图。交互概览图是交互图与活动图的混合物，可以把交互概览图理解为细化的活动图，在其中的活动都通过一些小型的顺序图来表示；也可以将其理解为利用标明控制流的活动图分解过的顺序图。
在UML中，顺序图、通信图、定时图和交互概览图又统称交互图(InteractiveDiagram)。交互图是表示各对象如何依据某种行为进行协作的模型，通常可以使用一个交互图来表示和说明一个用例的行为。

(12)组件图(ComponentDiagram)：又称为构件图，对应于实现视图。组件图用于描述每个功能所在的组件位置以及它们之间的关系。
(13)部署图(DeploymentDiagram)：又称为实施图，对应于环境视图。部署图用于描述软件中各个组件驻留的硬件位置以及这些硬件之间的交互关系。
在设计模式的学习中，我们将使用到类图、顺序图和状态图，因此本章只重点学习这三种图，其他UML图形请参考专门的UML教材，本书不予详细介绍。

模型元素

在UML中，模型元素包括事物以及事物与事物之间的联系。事物是UML的重要组
成部分，它代表任何可以定义的东西。事物之间的关系把事物联系在一起，组成有意义的结构模型。

每一个模型元素都有一个与之相对应的图形元素（如类、对象、消息、组件、节点等事物）以及它们之间的关系(如关联关系、泛化关系、依赖关系等)。

同一个模型元素可以在不同的UML图中使用，但是无论在哪个图中，同一个模型元素都需要保持相同的意义，使用相同的符号。

通用机制

UML提供的通用机制为模型元素提供额外的注释、修饰和语义等，主要包括规格说
明、修饰、公共分类和扩展机制四种。扩展机制允许用户对UML进行扩展，以便一个特定的方法、过程、组织或用户来使用。

1.2.2 类之间的关系（关联，依赖，泛化）

• 关联关系：单向 / 双向关联、自关联、聚合（整体 - 部分，可分离）、组合（整体 - 部分，不可分离）。
• 依赖关系：一个类使用另一个类的对象。
• 泛化关系：继承（类与类、接口与接口）。
• 实现关系：类实现接口。

第二章

2.2 单一职责原则
2.3 开闭原则（对扩展开放，对修改关闭）
2.4 里氏替换原则（所有基类（父类）的地方必须能透明地使用其子类的对象）
2.5 依赖倒转原则（高层模块不应该依赖低层模块，他们都应该依赖抽象）
2.6 接口隔离原则
2.7 合成复用原则（多用关联关系，少用继承关系）
2.8.3 迪米特法则实例（降低界面类和业务逻辑类之间的耦合度）

• 核心目标：提高软件的 可维护性 和 可复用性。

• 七大原则：

  1. 单一职责原则（SRP）：一个类只负责一项职责。
  2. 开闭原则（OCP）：对扩展开放，对修改关闭（通过抽象和继承实现）。
  3. 里氏代换原则（LSP）：子类可替换父类，且不破坏程序正确性。
  4. 依赖倒转原则（DIP）：依赖抽象而非具体类，高层模块不依赖低层模块。
  5. 接口隔离原则（ISP）：使用多个专门接口，避免依赖臃肿接口。
  6. 合成复用原则（CRP）：优先使用组合 / 聚合，而非继承。
  7. 迪米特法则（LoD）：对象间交互尽可能少，降低耦合。

第三章

3.2.3 设计模式的分类（创建型，结构型，行为型）

• 分类：

  • 按目的：创建型（工厂模式等）、结构型（适配器模式等）、行为型（观察者模式等）。
  • 按范围：类模式（通过继承实现）、对象模式（通过关联实现）。

  

• GoF 23 种模式：重点关注考试范围内的模式（见下文）。

• 表3.2（前两个）优先掌握 （如工厂方法、适配器、装饰、观察者），理解其类图与代码逻辑。

创建型模式

• 工厂方法模式：
  • 动机：将对象创建延迟到子类，符合开闭原则。
  • 结构：抽象工厂、具体工厂、抽象产品、具体产品。
  • 代码要点：抽象工厂声明创建方法，具体工厂实现创建逻辑。
• 抽象工厂模式：
  • 动机：创建相关产品族，一个工厂生产多个产品等级结构。
  • 结构：比工厂方法多产品族概念，具体工厂生产一组产品。

结构型模式

• 适配器模式：
  • 动机：转换不兼容接口，分为类适配器（继承）和对象适配器（组合）。
  • 代码要点：适配器类实现目标接口，调用适配者方法。
• 桥接模式：
  • 动机：分离抽象与实现，使两者可独立扩展（如抽象维度 + 实现维度）。
  • 结构：抽象类持有实现类接口引用，具体抽象类调用实现类方法。
• 装饰模式：
  • 动机：动态添加职责，避免继承层次爆炸。
  • 结构：抽象构件、具体构件、抽象装饰类、具体装饰类（组合关系）。
• 外观模式：
  • 动机：为子系统提供统一接口，简化客户端调用。
  • 结构：外观类封装子系统调用，客户端直接调用外观方法。
• 代理模式：
  • 动机：通过代理对象控制对真实对象的访问（如远程代理、虚拟代理）。
  • 结构：代理类与真实类实现相同接口，代理类持有真实类引用。

行为型模式

• 职责链模式：
  • 动机：请求沿链传递，直到有对象处理（如审批流程）。
  • 结构：抽象处理者定义后继引用，具体处理者判断是否处理请求。
• 观察者模式：
  • 动机：定义对象间一对多依赖，状态变化时通知所有观察者。
  • 结构：主题维护观察者列表，观察者实现更新接口。
• 状态模式：
  • 动机：对象状态变化时改变行为，状态转换由状态类管理。
  • 结构：上下文类持有状态对象，状态类实现具体行为。
• 策略模式：
  • 动机：封装算法族，使算法可互换（如排序策略、支付策略）。
  • 结构：策略接口、具体策略类、上下文类持有策略引用。
• 模板方法模式：
  • 动机：定义算法骨架，子类实现具体步骤（如流程固定，细节可变）。
  • 结构：抽象类声明模板方法，具体子类重写部分步骤。

第四章

表4.1（4颗星以上掌握代码）

优先掌握 重要星级高的模式

模式名称	定义	简单说明
简单工厂模式（4）	根据传入的参数即可返回所需的对象，而不需要知道具体类的类名	根据提供给它的数据，返回几 个可能类中的一个类的实例。 通常它返回的类都有一个公共的父类和公共的方法。简单工厂模式不属于GoF设计模式
工厂方法模式（5）	定义一个用于创建对象的接口，让子类决定将哪一个类实例化。工厂方法模式使一个类的实例化延迟到其子类	将某一类对象的创建过程封装在单独的类中，通过引人抽象层的方式来使得对象的创建和使用更为灵活
抽象工厂模式（5）	提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类	在一个类中可以创建多个不同类型的对象，这些对象所对应的类型都源于抽象层，使得系统具有极佳的扩展性和灵活性
建造者模式（2）	将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示	一步一步构造一个由多个部分组成的复杂对象
原型模式（3）	用原型实例指定创建对象的种类，并且通过复制这个原型来创建新的对象	通过复制已有对象创建出相似的其他对象
单例模式（4）	保证一个类仅有一个实例，并提供一个访问它的全局访问点	控制系统中所创建的对象实例的个数

简单工厂模式代码实例p64

工厂方法模式代码实例p83

抽象工厂模式代码实例p97

建造者模式类图

原型模式类图

单例模式代码实例p139