【软件工程】结构化设计：高内聚低耦合原则
考点频率：★★★★★（上午选择题必考，下午案例题也常涉及）
难度：⭐⭐
建议：理解内聚耦合的评价原则和判断准则，重点掌握评价模块设计质量的方法
1️⃣ 什么是“高内聚、低耦合”？
高内聚、低耦合是软件工程中模块化设计的核心原则，也是判断模块设计好坏的黄金标准。
用一个比喻来理解：
- 高内聚：一个模块就像一个专业的团队——团队成员各司其职但目标一致，每个人都围绕同一个核心任务工作。比如一个“财务计算”模块，团队里所有人都在做财务相关的事情，没人分心去做UI设计或网络通信。
- 低耦合：模块之间的关系就像合作公司——彼此之间有业务往来（调用接口），但各自内部怎么运作互不干涉。比如“订单模块”和“支付模块”通过API交互，支付模块改了内部算法，订单模块不需要跟着改。
一句话理解：低耦合是“管好自己的事，少管别人的闲事”；高内聚是“把自己那一亩三分地精耕细作好”。
2️⃣ 高内聚与低耦合的评价原则
判断一个设计是否符合高内聚、低耦合，可以从以下几个维度来评估：
| 评估维度 | 优秀设计表现（高内聚低耦合） | 糟糕设计表现（低内聚高耦合） |
|---|---|---|
| 单一职责 | 每个模块只负责一个明确的功能 | 一个模块既做数据计算，又写日志，还发邮件 |
| 接口简洁性 | 模块间接口简单清晰，参数数量少（建议≤4个） | 接口复杂，传递大量参数或复杂数据结构 |
| 变更影响面 | 修改一个模块只需在该模块内部进行 | 改一处代码，牵连好几个模块都要跟着改 |
| 复用性 | 模块可以在不同项目中直接使用 | 模块依赖太多外部条件，离开当前项目就用不了 |
| 可测试性 | 每个模块可以独立进行单元测试 | 测试一个模块必须先准备好一堆其他模块 |
| 变更隔离性 | 模块内部的修改不会扩散到外部调用方 | 修改模块内部实现，导致所有调用方都要改代码 |
| 可理解性 | 看一眼模块名就知道它大概做什么 | 看完模块全部代码也不知道它到底想干嘛 |
| 变化频率 | 不同模块的变化频率相互独立 | 需求一变，所有模块都得跟着大改 |
判断逻辑（实践经验）：如果新增一个功能时，你需要修改3个以上的模块才能完成 → 说明模块划分可能不合理，耦合度过高或内聚度不足。
3️⃣ 低内聚、高耦合的典型表现（反面案例）
在实际项目中，模块设计不良常表现为以下几种“症状”，这有助于你在选择题或案例题中快速判断模块质量问题：
3.1 低内聚的典型表现
- 代码臃肿：一个模块几千行代码，什么都往里塞，不知道它到底负责什么
- 职责发散：模块中的函数看起来“各有各的想法”，找不到一个共同的核心目标
- 频繁修改：只要有需求变更，这个模块总是要改，说明它承担了不该承担的责任
3.2 高耦合的典型表现
- 改一牵十：修改一个模块的接口，导致大量其他模块需要跟着改
- 全局变量满天飞：多个模块频繁读写同一个全局变量，数据流向混乱
- 循环依赖：模块A调用B，B又调用A，形成一个环
- 直接访问内部数据：模块A直接读写模块B的私有属性或缓存
4️⃣ 如何在设计中践行高内聚低耦合？
4.1 提高内聚的方法
| 方法 | 说明 |
|---|---|
| 单一职责 | 每个模块只做一件事情（功能内聚的目标） |
| 面向接口编程 | 模块之间通过接口协作，而非具体实现。即使模块内部分解为多个类，也通过接口暴露功能 |
| 合理拆分 | 当一个模块代码量超过200行或职责超过2个时，考虑进一步拆分 |
| 命名即文档 | 模块名要准确反映其职责（如TaxCalculator比Utils好） |
4.2 降低耦合的方法
| 方法 | 说明 |
|---|---|
| 减少参数数量 | 能传1个参数就别传3个；能用简单值就别传整个对象（避免标记耦合升为内容耦合） |
| 避免控制耦合 | 不要让调用方传控制变量来决定被调用方的行为——把“选哪条路”的决定权放在被调用方内部 |
| 避免全局变量 | 通过参数传递而非全局变量共享数据 |
| 遵循依赖倒置原则 | 高层模块不应依赖低层模块的实现细节 |
5️⃣ 典型例题
例题1：下列关于“高内聚、低耦合”原则的叙述中，正确的是（ ）。
A. 模块之间传递的数据越复杂，耦合度越低
B. 模块内部各元素之间联系越弱，内聚度越高
C. 高内聚、低耦合是模块化设计的理想目标
D. 高内聚必然导致模块之间的高耦合
解析：A错误——传递的数据越复杂，耦合度越高（数据耦合→标记耦合）；B说反了——内部联系越弱，内聚度越低；D错误——高内聚和低耦合是独立属性，一个模块内部做得好不代表它和外部的关系差。C正确。选C。
例题2（真题改编）：某系统在设计时，模块A直接通过访问模块B的全局变量来获取数据，这种设计违反了（ ）原则。
A. 高内聚
B. 低耦合
C. 高内聚和低耦合
D. 以上都不违反
解析：通过全局变量共享数据 →公共耦合，耦合度高，违反了“低耦合”原则。选B。
6️⃣ 记忆口诀
高内聚，模块内部一条心；低耦合，模块之间少操心。
接口要简单，依赖要清晰，改了不扩散，测了不牵连。
7️⃣ 小测验（评论区对答案）
以下哪种做法最有助于实现“低耦合”的设计目标？
A. 模块之间通过全局变量进行数据共享
B. 模块A调用模块B时，传递一个控制标志让B决定执行逻辑
C. 模块A和模块B通过定义清晰的接口进行交互，不共享内部实现
D. 模块A直接访问模块B的内部数据结构以提高效率
🔔本专栏日更，点击头像 → 专栏《软考中级高频考点》订阅，第一时间接收新内容
#软考中级 #软件设计师 #高内聚 #低耦合 #模块设计 #软件工程