文章目录
- 前言
- 一、面向对象分析
-
- [（一） OOD 概述](#（一） OOD 概述)
- [（二） OOD 金字塔模型 (四层结构)](#（二） OOD 金字塔模型 (四层结构))
- [（三）OOD 工作的两个抽象层次](#（三）OOD 工作的两个抽象层次)
- （四）设计模板的使用方法 (高频考点！)
-
- [**1. 核心设计原则**](#1. 核心设计原则)
- 2.核心考点总结 (精华背诵版)
- （五）OOA与OOD的区别
- 二、面向对象设计
-
- （一）软件设计概述
- （二）面向对象分析建模
-
- 1.模式的应用
-
- （1）模式的分类
-
- [架构模式（Architectural Patterns）](#架构模式（Architectural Patterns）)
- [设计模式（Design Patterns）](#设计模式（Design Patterns）)
- 习惯用法（Idioms）
- （2）MVC架构
- （3）模式之间的对比
- 总结
前言
提示：这里可以添加本文要记录的大概内容：
例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人都开启了学习机器学习，本文就介绍了机器学习的基础内容。
提示：以下是本篇文章正文内容，下面案例可供参考
一、面向对象分析
（一） OOD 概述
- 定义 ：将分析阶段的 OOA 模型 转换为为实现做准备的 OOD 模型。
- 核心目标：为软件实现做准备。
（二） OOD 金字塔模型 (四层结构)
OOD模型可归结为包含 4个层次 的金字塔。
| 层次 (由底向上) | 英文关键名 | 核心描述与考点 |
|---|---|---|
| 1. 子系统设计层 | Subsystem Design | 描述系统总体结构 。包含子系统及其协作关系。 |
| 2. 类和对象层 | Class and Object | 包含类层次关系 （通用化->特殊化）和每个对象的设计表示。 |
| 3. 消息层 | Message | 描述对象间的消息模型 ，建立系统的内部与外部接口。 |
| 4. 责任层 | Responsibility | 包含每个对象的属性 与操作 的数据结构 和算法设计。 |
记忆口诀：系（子系统）类（类对象）消（消息）责（责任）。
（三）OOD 工作的两个抽象层次
| 层次 | 英文关键名 | 核心工作与构件 |
|---|---|---|
| 系统设计 | System Design | 设计整个系统的体系结构 。涉及 4类构件 ： 1. 领域构件 (Domain Component) 2. 人机交互构件 (Human-Interaction Component) 3. 任务管理构件 (Task Management Component) 4. 数据管理构件 (Data Management Component) |
| 对象设计 | Object Design | 将问题域概念转换为计算机域概念 。重点是定义： - 实现相关的类、关联、属性、操作 。 - 对象的算法 与数据结构。 |
（四）设计模板的使用方法 (高频考点！)
设计新系统时，使用设计模板有两种方法：
| 方法 | 英文关键名 | 描述与选择原则 |
|---|---|---|
| 继承 | Inheritance | 通过扩展已有类（父类）来获得其特性。 |
| 复合 | Composition | 在新类中包含（作为成员）已有类的对象。 |
1. 核心设计原则
当两种选择（继承 vs 复合）并存时，Composition (复合) 应该优先于 Inheritance (继承)。
- 原因 ：复合通常能提供更好的封装性 、灵活性 和松耦合，避免继承可能带来的脆弱基类等问题。
2.核心考点总结 (精华背诵版)
- OOD金字塔四层名称与顺序 ：
子系统设计->类和对象->消息->责任。 - 系统设计的4类构件：领域、人机交互、任务管理、数据管理。
- 对象设计的核心 ：完成从问题域 到计算机域 的转换，具体设计数据结构 和算法。
- 继承与复合的选择 ：
Composition over Inheritance(复合优于继承)。这是最重要的设计原则之一，务必理解其含义和原因。
复习提示：重点记忆金字塔模型各层名称、4类系统构件，以及"复合优于继承"的原则。这些是选择题、填空题和简答题的高频考点。
（五）OOA与OOD的区别
| 对比维度 | OOA (面向对象分析) | OOD (面向对象设计) |
|---|---|---|
| 英文全称 | Object-Oriented Analysis | Object-Oriented Design |
| 核心目标 | 理解问题域 ，识别系统需求 做什么 (What to do) | 规划解决方案 ，设计系统实现 怎么做 (How to do) |
| 关注焦点 | 问题域 (Problem Domain) 真实世界中的概念、实体、关系 | 解决方案域 (Solution Domain) 计算机世界的实现机制 |
| 抽象层次 | 概念级抽象 关注业务逻辑、用户需求 | 实现级抽象 关注技术实现、系统架构 |
| 模型类型 | 分析模型 （如：用例图、概念类图、领域模型） | 设计模型 （如：设计类图、序列图、构件图、部署图） |
| 核心产出 | - 需求规格说明 - 用例模型 - 领域概念模型 | - 系统架构设计 - 详细类设计 - 接口设计 |
| 主要活动 | 1. 识别参与者与用例 2. 建立领域模型 3. 分析系统行为 | 1. 架构设计（4类构件） 2. 详细类设计 3. 数据结构与算法设计 |
| 设计决策 | 较少技术决策 侧重于业务规则、领域逻辑 | 大量技术决策 选择设计模式、框架、平台等 |
| 时间顺序 | 前期阶段 （分析阶段） | 后续阶段 （设计阶段） |
| 独立性 | 实现无关 不考虑编程语言、数据库等 | 实现相关 为具体实现做准备 |
| 关键特征 | - 概念性 - 业务导向 - 稳定性高 | - 技术性 - 实现导向 - 可调整性强 |
二、面向对象设计
设计有两种主流方法，一种是以结构化程序设计为基础的结构化软件设计和由面向对象方法导出的面向对象软件设计
（一）软件设计概述
设计的目标：细化解决方案的可视化设计模型，确保设计模型最终能平滑的过渡到程序代码
1.概念
（1）模块与构件
| 对比维度 | 模块 (Module) | 构件/组件 (Component) |
|---|---|---|
| 定义 | 代码组织单元：将相关代码封装在一起，实现特定功能或数据抽象。 | 部署/复用单元：具有明确定义接口、可独立部署、可复用的软件单元。 |
| 抽象层次 | 较低层次：通常是代码级的封装（如类、函数、包）。 | 较高层次：系统级的构建块，可能包含多个模块。 |
| 粒度 | 粒度较小，关注内部实现细节。 | 粒度较大，关注整体功能和服务。 |
| 独立性 | 依赖其他模块，通常不能独立运行。 | 高度独立，可以独立部署、替换、复用。 |
| 接口 | 接口可能较简单或隐式（如函数参数、类方法）。 | 明确的接口规范（如API、服务契约）。 |
| 复用性 | 主要在源代码级别复用。 | 主要在二进制/运行时级别复用。 |
| 设计关注点 | 内部结构：如何组织代码以实现功能。 | 外部交互：如何通过接口与其他构件协作。 |
| 关系类型 | 描述 |
|---|---|
| 包含关系 | 一个构件通常由多个模块组成，构件是模块的更高层次封装。 |
| 演变关系 | 模块是构件的基础，通过良好的模块设计可以演进为可复用的构件。 |
| 设计原则 | 两者都遵循高内聚、低耦合的设计原则，只是应用在不同抽象层次。 |
| 面向对象设计 | 在OOD中： • 模块化设计 体现在类、对象的设计上。 • 构件化设计体现在子系统、4类构件的设计上。 |
（2）抽象与细化
| 对比维度 | 抽象 (Abstraction) | 细化 (Refinement) |
|---|---|---|
| 核心定义 | 隐藏细节，提取本质 。 关注"做什么"（What），忽略"怎么做"。 | 补充细节，逐步具体化 。 关注"怎么做"（How），将高层描述转化为具体步骤。 |
| 思维方向 | 自底向上 的归纳过程。 （从具体细节中提取通用模型） | 自顶向下 的分解过程。 （从高层模型逐步分解出具体细节） |
| 目的 | 降低复杂度，管理认知负荷，聚焦核心问题。 | 为实现做准备，提供可执行的详细说明。 |
| 输出结果 | 高层模型、接口、规范、概念。 | 详细设计、算法、数据结构、具体实现步骤。 |
| 关注焦点 | 外部视角（接口、功能、行为）。 | 内部视角（实现逻辑、数据结构、算法效率）。 |
（3）信息隐藏
将系统分解为模块的指导思想叫做信息隐藏，目的是为了提高软件各模块的独立性
（4）软件复用
充分利用已有的现成构件
2.软件设计的任务
第一个阶段是概要设计，包括结构设计和接口设计，并编写概要设计文档，第二阶段是详细设计，确定各个软件部件的数据结构和操作，产生描述个软件部件的详细设计文档。
3.模块化设计
分解，将软件分解为若干模块，控制在软件的最小成本区（复杂度及工作量 与 模块之间的联系 的平衡）
（1）模块独立性
概括了把软件划分为模块时要遵守的准则，也是判断模块构造是否合理的标准。
可从模块本身的内聚（块内联系）和模块之间的耦合（块间联系）度量。
模块独立性高，则高内聚低耦合
（二）面向对象分析建模
1.模式的应用
模式（Pattern） 是针对在特定上下文 中反复出现的设计问题 的可重用解决方案。它是经验的总结和抽象，提供了一种标准化的解决思路。
核心要素：
- 问题（Problem）：描述在什么情况下使用此模式。
- 解决方案（Solution）：描述设计的组成部分、关系和职责。
- 效果（Consequences）：应用此模式的利弊权衡。
（1）模式的分类
架构模式（Architectural Patterns）
| 维度 | 说明 |
|---|---|
| 层级 | 最高层级，影响整个系统的宏观结构 |
| 关注点 | 系统的整体结构和组织方式，定义子系统、构件及其关系 |
| 范围 | 影响整个应用或大型子系统 |
| 例子 | • MVC (Model-View-Controller) • 分层架构 (Layered Architecture) • 微内核 (Microkernel) • 客户端-服务器 (Client-Server) |
| 关键特征 | - 定义系统的骨架 - 关注子系统的职责划分和通信机制 |
设计模式（Design Patterns）
| 维度 | 说明 |
|---|---|
| 层级 | 中等层级，关注子系统或模块内部结构 |
| 关注点 | 解决特定设计问题，优化类和对象的结构与交互 |
| 范围 | 影响模块或组件内部，不决定整体架构 |
| 例子 | 创建型 ：Singleton, Factory Method 结构型 ：Adapter, Decorator 行为型：Observer, Strategy |
| 关键特征 | - 提供可复用 的设计方案 - 提高代码灵活性 、可维护性 |
习惯用法（Idioms）
| 维度 | 说明 |
|---|---|
| 层级 | 最低层级，与具体编程语言相关 |
| 关注点 | 解决语言特定的实现问题，是编程惯例 |
| 范围 | 影响具体类或方法的实现 |
| 例子 | • C++ ：RAII (Resource Acquisition Is Initialization) • Java ：使用iterator()方法遍历集合 • Python ：使用with语句管理资源 |
| 关键特征 | - 语言特定 - 体现语言的最佳实践和特性 |
（2）MVC架构
MVC三层架构（Model，View，Contoller）
模型层：对业务逻辑的处理
视图层：显示数据和将用户请求和输入传给控制器
控制器层：调用不同的模型处理用户请求，选择不同的视图显示系统信息。
（3）模式之间的对比
| 维度 | 架构模式 | 设计模式 | 习惯用法 |
|---|---|---|---|
| 抽象层级 | 宏观（系统级） | 中观（模块级） | 微观（代码级） |
| 关注范围 | 整个系统的结构 | 模块/组件的设计 | 具体实现细节 |
| 语言依赖 | 语言无关 | 语言无关 | 语言相关 |
| 稳定性 | 最稳定，难更改 | 较稳定 | 相对容易更改 |
| 影响范围 | 影响整个系统开发 | 影响部分模块 | 影响具体编码 |
关系总结：
- 架构模式 为系统提供整体框架
- 设计模式 在架构框架内解决特定设计问题
- 习惯用法 在具体编程语言中实现设计模式的具体细节
总结
提示：这里对文章进行总结：
例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。