功能内聚（Functional Cohesion）是模块化设计中最高级别的内聚类型

功能内聚（Functional Cohesion）是模块化设计中最高级别的内聚类型。在这种内聚形式下，模块中的所有处理元素都紧密关联，并且共同协作完成一个单一、明确的功能。这意味着模块只做一件事，并且每部分都对实现该功能有直接贡献。功能内聚的模块通常具有高可读性、高可维护性和良好的可重用性。

例如，一个用于“计算员工月工资”的模块，其中包含获取出勤记录、计算加班费、扣除社保和个税、最终汇总工资等操作，这些操作全部围绕“计算工资”这一单一功能展开，就体现了功能内聚。

相比其他类型的内聚（如顺序内聚、通信内聚等），功能内聚是最理想的模块设计目标，因为它最大限度地降低了模块与外部的耦合度。
功能内聚（Functional Cohesion）与其他类型的内聚（如顺序内聚、逻辑内聚）的主要区别在于模块内部元素之间的关联程度以及它们共同完成任务的方式。以下是各类内聚的对比说明：

1. 功能内聚（Functional Cohesion）

   • 模块内所有组件共同完成一个单一、明确的功能。
   • 所有操作都直接为实现该功能服务，无多余行为。
   • 示例：一个函数专门“计算贷款利息”，输入本金、利率和时间，输出利息。

2. 顺序内聚（Sequential Cohesion）

   • 模块中的处理元素按特定顺序执行，前一个步骤的输出是下一个步骤的输入。
   • 元素之间存在数据流依赖，但整体不聚焦于单一功能。
   • 示例：先读取用户输入 → 验证格式 → 存入数据库。这三个步骤有关联，但分属不同功能阶段。

3. 逻辑内聚（Logical Cohesion）

   • 模块将多个逻辑上相关但功能不同的操作组合在一起，通常通过参数控制执行哪个子功能。
   • 虽然看起来“类别相似”，但内部各部分并无紧密协作。
   • 示例：一个“设备控制”模块根据传入参数决定启动打印机、扫描仪或摄像头——它们都是外设，但功能完全不同。

关键区别总结：

类型	内部关联性	功能专注度	可维护性	设计优劣
功能内聚	极强（统一目标）	单一明确	高	最优
顺序内聚	中等（数据流依赖）	多步流程	中	较好
逻辑内聚	弱（仅逻辑分类）	多个功能	低	不推荐

因此，功能内聚是模块设计的理想目标，而顺序内聚尚可接受，逻辑内聚则应尽量避免。
判断一个模块是否达到功能内聚，可以通过以下几个关键标准和实践方法进行评估：

1. 单一职责原则（Single Responsibility Principle, SRP）

• 模块是否只做一件事？如果可以用一句话清晰、简洁地描述其功能（如“验证用户登录凭证”），而无需使用“并且”“然后”等连接词，则很可能实现了功能内聚。
• ✅ 示例：calculateTax(income) —— 只负责计算税额。
• ❌ 反例：processOrderAndSendEmail() —— 同时处理订单和发送邮件，职责不单一。

2. 所有元素都为同一目标服务

• 检查模块中的每个函数、变量或语句是否都直接参与实现该核心功能。
• 如果存在某部分代码仅在特定条件下才执行，或服务于不同目的，则可能不是功能内聚。

3. 可重用性高

• 功能内聚的模块通常可以在其他上下文中被完整复用。例如，“加密字符串”模块可在多个系统中通用。
• 若模块因逻辑混杂而无法独立使用，则内聚性差。

4. 副作用最小化

• 功能内聚的模块应尽量避免修改外部状态或产生意外影响（即“纯函数”风格更优）。
• 若调用一个模块后导致多个无关系统状态变化，说明其内部可能包含多个功能。

5. 测试简单明确

• 功能内聚的模块易于编写单元测试：输入明确、输出可预测、测试用例围绕单一行为设计。
• 如果需要大量模拟（mock）不同场景来测试一个模块，可能意味着它承担了过多职责。

6. 重构提示法

• 使用以下问题自检：
  • 能否给这个模块起一个精确的名字？
  • 是否所有方法都被频繁一起调用？
  • 删除其中某个部分会不会影响整体功能完整性？

---

✅ 示例：功能内聚的模块

def validate_email(email):
    """验证邮箱格式是否合法"""
    import re
    pattern = r'^[\w\.-]+@[\w\.-]+\.\w+$'
    return re.match(pattern, email) is not None

• 只做一件事：验证邮箱。
• 所有代码都为此服务。
• 易于测试、复用。
•