内聚设计原则：从偶然到功能的七个层次

内聚，说白了就是一个模块内部元素之间的紧密程度。我做了十几年嵌入式系统，见过太多因为内聚性差导致的维护噩梦。今天咱们就把这七种内聚掰开揉碎，看看它们到底长什么样。

什么是内聚？为什么它如此重要？

内聚度衡量的是一个模块内部各元素（函数、数据、语句）之间的关联程度。高内聚意味着模块内部元素紧密协作，共同完成一个清晰的目标。

高内聚的好处，我总结为三点：

• 可维护性提升：修改一个功能时，你只需要改动一个模块。我曾经在一个项目中，因为一个模块内聚性差，改一个bug牵扯了五个文件，改完又出了三个新bug。
• 可复用性增强：高内聚的模块可以独立移植到其他项目。你想想看，一个只做CRC校验的函数，是不是比一个既做校验又写日志又发数据的函数更容易复用？
• 可测试性改善：测试一个功能明确的模块，比测试一个功能混杂的模块简单得多。

七种内聚类型：从高到低

内聚度是一个连续谱，从最高到最低分为七种。我习惯把它们分成三档：理想型（功能、顺序、通信）、可接受型（过程、时间）、应避免型（逻辑、偶然）。

内聚类型	内聚度	典型特征	我的评价
功能内聚	最高	模块内所有元素共同完成一个功能	理想目标
顺序内聚	高	一个元素的输出是下一个元素的输入	优秀
通信内聚	较高	多个元素操作同一数据	良好
过程内聚	中等	按执行顺序组合，但数据不相关	可接受
时间内聚	较低	因在同一时间执行而组合	勉强接受
逻辑内聚	低	用参数控制执行不同逻辑	应重构
偶然内聚	最低	毫无关联的元素被随意放在一起	必须避免

功能内聚：最高境界

功能内聚是每个模块只做一件事，并且把这件事做好。模块内所有元素都为完成同一个功能服务。

// 功能内聚示例：计算CRC32校验值
uint32_t crc32_calculate(const uint8_t *data, uint32_t len) {
    uint32_t crc = 0xFFFFFFFF;
    for (uint32_t i = 0; i < len; i++) {
        crc ^= data[i];
        for (int j = 0; j < 8; j++) {
            if (crc & 1) {
                crc = (crc >> 1) ^ 0xEDB88320;
            } else {
                crc >>= 1;
            }
        }
    }
    return crc ^ 0xFFFFFFFF;
}

这个函数只做一件事：计算CRC32。它不写日志、不发数据、不保存结果。这就是功能内聚的典型代表。

顺序内聚：流水线式协作

顺序内聚是指模块内一个元素的输出直接作为下一个元素的输入。它们像流水线一样，前一道工序的产出就是后一道工序的原料。

// 顺序内聚示例：数据采集-处理-存储流水线
void data_pipeline(void) {
    raw_data_t raw = sensor_acquire();    // 采集原始数据
    processed_data_t proc = process(raw); // 处理数据
    storage_save(&proc);                  // 存储结果
}

这三个函数必须按顺序执行，前一个的输出是后一个的输入。但它们各自职责清晰，可以独立测试和复用。

通信内聚：共享数据的工作组

通信内聚是指模块内多个元素操作同一组数据。它们因为共享数据而组合在一起。

// 通信内聚示例：操作同一个环形缓冲区
ring_buffer_t rb;

void rb_init(void) { /* 初始化缓冲区 */ }
uint32_t rb_write(const uint8_t *data, uint32_t len) { /* 写入数据 */ }
uint32_t rb_read(uint8_t *buf, uint32_t max_len) { /* 读取数据 */ }
uint32_t rb_available(void) { /* 返回可用数据量 */ }

这四个函数都操作同一个环形缓冲区。它们因为共享数据而组合，但每个函数的功能是独立的。

过程内聚：按顺序但不共享数据

过程内聚是指模块内元素按执行顺序组合，但元素之间没有数据传递。它们只是因为"恰好需要按这个顺序执行"而被放在一起。

// 过程内聚示例：系统初始化步骤
void system_init(void) {
    gpio_init();      // 初始化GPIO
    timer_init();     // 初始化定时器
    uart_init();      // 初始化串口
    spi_init();       // 初始化SPI
}

这些初始化函数必须按顺序执行（比如先初始化GPIO才能初始化SPI），但它们之间没有数据传递。过程内聚比功能内聚弱，但在初始化代码中很常见。

时间内聚：同一时刻的临时组合

时间内聚是指模块内元素因为需要在同一时间执行而被组合在一起。最典型的例子就是中断服务函数。

// 时间内聚示例：定时器中断服务函数
void TIM2_IRQHandler(void) {
    if (TIM_GetITStatus(TIM2, TIM_IT_Update) != RESET) {
        TIM_ClearITPendingBit(TIM2, TIM_IT_Update);
        
        led_toggle();           // 翻转LED
        adc_start_conversion(); // 启动ADC转换
        check_communication();  // 检查通信状态
    }
}

这三个操作只是因为"都需要每1ms执行一次"而被放在同一个中断里。它们之间没有功能关联，也没有数据共享。

时间内聚是不得已的选择。我的经验是：如果中断里要做的事情太多，就创建一个任务队列，让中断只负责触发，具体工作交给任务处理。

逻辑内聚：用参数控制的分支

逻辑内聚是指模块内包含多个逻辑分支，通过参数选择执行哪个分支。这种模块往往有一个switch-case或if-else结构。

// 逻辑内聚示例：一个函数处理所有类型的数据
void process_data(int type, const uint8_t *data, uint32_t len) {
    switch (type) {
        case TYPE_TEMPERATURE:
            // 处理温度数据
            break;
        case TYPE_HUMIDITY:
            // 处理湿度数据
            break;
        case TYPE_PRESSURE:
            // 处理气压数据
            break;
        case TYPE_LIGHT:
            // 处理光照数据
            break;
    }
}

这个函数处理四种不同类型的数据，但被强行塞到一个函数里。逻辑内聚的模块往往难以维护——修改一个分支可能影响其他分支，而且测试时需要覆盖所有分支。

偶然内聚：最糟糕的设计

偶然内聚是指模块内元素之间没有任何有意义的关联，只是被随意放在一起。这种模块通常是因为"不知道放哪里好"或者"懒得新建文件"而产生的。

// 偶然内聚示例：一个"杂物间"模块
void delay_ms(uint32_t ms) { /* 延时函数 */ }
uint32_t get_system_tick(void) { /* 获取系统滴答 */ }
void set_led_color(uint8_t r, uint8_t g, uint8_t b) { /* 设置LED颜色 */ }
int is_prime(uint32_t n) { /* 判断素数 */ }
float calculate_average(float *arr, uint32_t len) { /* 计算平均值 */ }

这个模块里有延时函数、系统时间获取、LED控制、素数判断、平均值计算——它们之间没有任何关系。这就是典型的偶然内聚。

内聚层次全景图

下面这张图展示了七种内聚类型的关系和评价：

如何在实际项目中应用内聚原则？

说了这么多理论，咱们聊聊实战。我在项目中总结了一套判断内聚性的方法：

1. 命名测试：给模块起名字。如果你能用一个名词或动词短语准确描述它，说明内聚性好。如果名字里带"and"或"or"，比如"采集并处理并发送"，那就要小心了。
2. 修改测试：当需求变化时，看需要修改几个模块。理想情况下，一个需求变化只影响一个模块。
3. 复用测试：看这个模块能否独立移植到其他项目。如果能，说明内聚性好。

总结：内聚设计的核心要点

内聚设计不是教条，而是指导原则。在实际项目中，你不可能所有模块都做到功能内聚——比如初始化代码天然就是过程内聚，中断服务函数天然就是时间内聚。关键是要有意识地去追求高内聚，避免低内聚。

记住一句话：一个模块只做一件事，并且把这件事做好。如果你能做到这一点，你的代码就会更容易维护、更可靠、更可复用。