文章目录
一、核心思想：模块化与对象化的设计哲学
系统设计的本质是"分而治之"的工程思维在软件领域的体现。 无论是结构化设计还是面向对象设计，其核心目标都是将复杂的系统分解为相对独立、易于理解和管理的组件。
1、结构化设计的核心思想
结构化设计基于"自顶向下、逐步求精"的思维模式。它认为复杂系统可以通过层次化的模块分解来解决，每个模块都有明确的输入、输出和处理逻辑。 这种设计的精髓在于"高内聚、低耦合"——模块内部紧密协作，模块之间松耦合连接。
想象一下建造一座大厦：结构化设计就像先设计整体框架（概要设计），然后细化每个房间的功能（详细设计）。每个房间（模块）都有明确的用途，房间之间通过走廊（接口）连接，但房间内部的设计相对独立。
2、面向对象设计的核心思想
面向对象设计基于"现实世界映射"的思维模式。它认为软件系统应该像现实世界一样，由各种对象组成，每个对象都有自己的属性和行为。 这种设计的精髓在于"封装、继承、多态"——对象内部细节隐藏，对象间通过消息传递协作。
继续用大厦的比喻：面向对象设计就像设计一个智能大厦，每个房间（对象）都有自己的智能系统（属性和方法），房间之间可以相互通信（消息传递），而且不同类型的房间可以继承共同的特征（继承）。
3、两种设计方法的本质区别
结构化设计关注"功能分解"，面向对象设计关注"对象协作"。 结构化设计问的是"这个系统要做什么功能？“，面向对象设计问的是"这个系统有哪些对象？它们如何协作？”
在实际应用中，两种方法往往结合使用：用结构化设计构建系统架构，用面向对象设计实现具体功能。
二、结构化设计知识点
1、设计阶段
| 阶段 | 定义与作用 | 示例 |
|---|---|---|
| 概要设计 | 将功能需求分配给软件模块，形成模块结构图 从宏观角度规划软件架构，确定模块功能和调用关系 | 学生管理系统中，将学生信息录入、成绩管理、考勤管理分配到不同模块 |
| 详细设计 | 针对每个模块选择技术手段和处理方法 细化软件设计，指导程序员进行代码编写 | 确定数据存储格式、选择验证算法、设计处理流程 |
2、设计原则
| 原则 | 定义与具体要求 | 作用 |
|---|---|---|
| 模块独立性 | 高内聚、低耦合 高内聚：模块内部元素联系紧密，功能单一明确 低耦合：模块间依赖程度低，修改影响小 | 提高模块的可理解性和可维护性 |
| 模块大小适中 | 避免过大或过小 过大：代码复杂难以理解和维护 过小：功能零碎，增加模块间交互成本 | 平衡模块的复杂度和交互成本 |
| 多扇入、少扇出 | 提高模块复用性，降低复杂度 扇入：模块被其他模块调用的次数，多扇入提高复用性 扇出：模块调用其他模块的数量，少扇出降低复杂度 | 提高模块复用性，降低系统复杂度 |
| 控制深度和宽度 | 避免层次过深或过宽 深度：模块结构层次数，过深增加理解和维护难度 宽度：同一层次模块数，过宽增加横向复杂度 | 保持系统结构的清晰性 |
3、 内聚类型（从低到高）
| 类型 | 定义与特点 | 示例 |
|---|---|---|
| 偶然内聚 | 模块内任务无关联 最差的内聚形式，任务随意组合 | 模块包含文件读取、界面显示、数据加密等无关联操作 |
| 逻辑内聚 | 完成逻辑相关但联系不紧密的任务 任务逻辑相关但协同性不强 | 处理各种类型数据校验（数字、字符串等） |
| 时间内聚 | 必须在同一时间执行的任务 任务在同一时间间隔内执行 | 系统启动时的初始化操作（数据库连接、配置文件加载） |
| 过程内聚 | 按特定次序执行的相关任务 任务相关且必须按特定顺序执行 | 订单处理流程（验证→扣库存→更新状态） |
| 通信内聚 | 操作同一数据结构 所有处理元素集中在同一数据结构上 | 学生信息的增删改查操作 |
| 顺序内聚 | 必须顺序执行的相关任务 比过程内聚更强调顺序关联性 | 文件处理（打开→读取→关闭） |
| 功能内聚 | 完成单一功能，各部分协同工作 最高程度的内聚，各部分缺一不可 | 加密模块专门负责数据加密处理 |
耦合类型（从低到高）
| 类型 | 定义与特点 | 示例 |
|---|---|---|
| 非直接耦合 | 通过主模块控制，无直接联系 耦合程度最低，模块间无直接交互 | 模块A和B通过主模块调用，A和B无直接联系 |
| 数据耦合 | 通过参数传递简单数据 耦合度较低，传递简单数据 | 计算模块接收数值参数进行运算 |
| 标记耦合 | 通过参数传递数据结构 比数据耦合稍高，传递复杂数据 | 传递学生信息结构体（姓名、年龄等字段） |
| 控制耦合 | 传递控制信息 传递的信息控制模块内部逻辑 | 传递标志位决定采用何种算法 |
| 外部耦合 | 访问同一全局变量 多个模块访问同一全局变量 | 多个模块直接访问全局计数器变量 |
| 公共耦合 | 访问同一公共数据环境 多个模块访问共享数据环境 | 访问共享数据库或内存区域 |
| 内容耦合 | 直接访问模块内部数据 耦合程度最高，破坏模块独立性 | 直接访问模块内部数据或不经正常入口进入 |
模块四要素
| 要素 | 定义与作用 | 示例 |
|---|---|---|
| 输入和输出 | 模块与外部交互的接口 定义模块的对外接口 | 计算模块接收两个数字，返回计算结果 |
| 处理功能 | 模块的核心操作 实现模块的特定功能 | 图像识别模块的特征提取、模式匹配操作 |
| 内部数据 | 模块内部使用的数据 支持模块内部处理功能的实现 | 文件管理模块记录当前打开文件列表 |
| 程序代码 | 实现模块功能的具体代码 定义模块的逻辑和操作流程 | 用Python编写的排序函数代码 |
三、面向对象设计知识点
设计过程
分析模型构建
| 内容与定义 | 示例 |
|---|---|
| 用例模型：描述系统功能及参与者与系统交互 | 电商系统中"用户下单""商家发货"等用例及参与者交互 |
| 领域模型：描述系统问题域中的概念、实体及其关系 | 电商系统中"用户"“商品”"订单"类及关联关系 |
设计阶段
| 内容与定义 | 示例 |
|---|---|
| 用例实现方案：确定用例的实现方式和流程 | "用户下单"用例：库存检查→订单生成→支付处理 |
| 技术支撑：选择技术框架、工具和平台 | 电商系统选用Spring Boot + MySQL技术栈 |
| 用户界面：设计用户与系统交互界面 | 商品展示页面、购物车界面等设计 |
| 细化设计模型：对类和对象进一步细化 | "订单"类细化订单状态属性、订单操作方法 |
设计模型产出
| 内容与定义 | 示例 |
|---|---|
| 架构图：展现系统整体架构和模块划分 | 用户管理、商品管理、订单管理等包 |
| 用例实现图：展示用例实现中对象交互过程 | "用户下单"用例的顺序图展示对象交互 |
| 类图：完整精确描述系统中类、对象、属性、方法及关系 | 电商系统完整类图涵盖"用户"“商品”"订单"类 |
| 其他设计图：状态图、活动图等 | "订单"类状态图展示从创建到完成的状态变迁 |
类分类
| 类型 | 定义与作用 | 示例 |
|---|---|---|
| 边界类 | 负责系统与外部环境交互 实现系统与外部设备、系统或用户之间的数据传输和交互 | 显示屏、API接口、用户界面 |
| 控制类 | 处理应用逻辑、业务逻辑和数据访问逻辑 协调和控制系统内部的操作流程 | 身份验证器、订单处理控制类 |
| 实体类 | 表示系统中的数据实体 存储相关数据信息，是系统数据的载体 | 学员类、课程类 |
设计原则
| 原则 | 定义与作用 | 示例 |
|---|---|---|
| 单一职责原则 | 设计目的单一的类 降低类的复杂度，提高可读性和可维护性 | 用户信息类只负责存储和管理用户基本信息 |
| 开放-封闭原则 | 对扩展开放，对修改封闭 通过扩展满足需求变化，保证系统稳定性 | 通过扩展促销类实现新促销策略，不修改原有代码 |
| 李氏替换原则 | 子类可以替换父类 确保继承体系中子类能无缝替换父类 | 正方形类作为矩形类的子类，应满足矩形类的所有行为 |
| 依赖倒置原则 | 依赖抽象而非具体实现 降低模块间耦合度，提高系统灵活性 | 业务逻辑层依赖数据访问接口，而非具体实现类 |
| 接口隔离原则 | 使用多个专门接口而非单一总接口 避免接口臃肿，提高系统可维护性 | 分别定义绘制圆形、矩形等图形的接口 |
| 组合重用原则 | 优先使用组合而非继承 组合比继承更灵活，降低类间耦合度 | 通过组合"移动""攻击"等行为类构建角色 |
| 迪米特原则 | 对象间耦合应尽量松散 降低系统耦合度，提高系统稳定性 | 员工类只需了解直接交互的对象，如上级领导 |
记住：系统设计的核心是平衡——在功能、性能、可维护性、可扩展性之间找到最佳平衡点。
扫一扫
1016
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
