📚 课程目录第1章架构设计概述

一、架构设计概述：什么是模块化、低耦合、高内聚？

各位工程师朋友，咱们直接开门见山。

做嵌入式开发，尤其是项目规模上来以后，最怕什么？最怕改一个 bug 引出三个新 bug，最怕一个功能要动七八个文件，最怕新同事来了三个月还不敢动代码。这些问题的根源，说白了就是架构没设计好。

今天这第一讲，咱们先把三个最核心的概念掰扯清楚：模块化、低耦合、高内聚。别觉得这是理论空话，我做了十几年嵌入式，踩过的坑有一半都是因为没搞懂这三个词。

1.1 模块化：把大象装进冰箱，分几步？

模块化，就是把一个复杂系统拆成若干个独立的功能单元。每个单元负责一件事，单元之间通过明确的接口通信。

举个例子。你写一个智能温控器，功能包括：读取温度传感器、控制加热器、显示屏幕、按键处理、Wi-Fi 通信。如果你把所有代码都塞进一个 main.c，那恭喜你，你给自己挖了一个大坑。

模块化的核心原则：

单一职责：一个模块只做一件事，并且把它做好。
接口清晰：模块对外暴露的接口要少而精，内部实现对外部不可见。
独立编译：每个模块可以单独编译、测试、替换。

我在一个车载项目中见过一个"神级"代码，一个 .c 文件一万多行，全局变量满天飞。后来要加一个新传感器，改了一个全局变量，结果三个功能模块同时崩溃。嗯，那个项目最后重写了。

1.2 低耦合：别让模块之间"藕断丝连"

耦合度，衡量的是模块之间的依赖程度。低耦合，就是模块之间尽量少关联，关联的部分尽量简单。

耦合类型	描述	危害程度
内容耦合	一个模块直接修改另一个模块的内部数据	极高
公共耦合	多个模块共享同一个全局变量	高
控制耦合	一个模块传递控制标志给另一个模块	中
数据耦合	模块之间只通过参数传递基本数据	低
消息耦合	模块之间通过消息队列或事件驱动通信	最低

我曾经踩过的坑： 在一个物联网网关项目中，我用了三个全局变量来传递传感器数据。结果调试时发现，A 模块改了数据，B 模块没来得及读就被 C 模块覆盖了。查了三天，最后发现是时序问题。从那以后，我定了一条铁律：全局变量能不用就不用，非用不可也要加锁或使用消息队列。

低耦合的好处很明显：

修改一个模块，不影响其他模块。
模块可以独立测试。
团队可以并行开发不同模块。

1.3 高内聚：模块内部要"拧成一股绳"

内聚度，衡量的是模块内部元素之间的关联程度。高内聚，就是模块内部的函数、变量、数据结构都紧密围绕同一个功能目标。

我见过一种代码：一个模块叫"utils.c"，里面放了 CRC 校验、字符串处理、延时函数、LED 控制、日志打印……这哪是工具模块，这分明是垃圾堆。你想想看，如果这个模块出了问题，你根本不知道是哪个功能引起的。

内聚的层次（从低到高）：

偶然内聚：代码被放在一起只是因为"刚好都在这里"。
逻辑内聚：功能相似但不同，比如"所有与通信相关的函数"。
时间内聚：因为执行时间相近而放在一起，比如"初始化函数"。
功能内聚：所有元素共同完成一个单一功能，这是理想状态。

我个人习惯，每个模块只做一件事。比如一个温度传感器驱动模块，它只负责：初始化传感器、读取温度值、转换单位。别的什么都不管。这样测试时，我只需要 mock 一个 I2C 接口，就能把整个模块测透。

1.4 为什么嵌入式软件特别需要这种架构？

你可能会问：桌面软件不也需要吗？为什么嵌入式要单独强调？

原因有三：

资源受限：MCU 的 RAM 和 Flash 就那么点，代码耦合度高会导致大量冗余代码，浪费空间。模块化可以精确控制每个模块的资源占用。
实时性要求：低耦合的架构更容易做任务优先级管理，避免一个模块的延迟拖垮整个系统。我在一个电机控制项目中，就因为一个日志模块占用了太多 CPU 时间，导致控制周期抖动，电机嗡嗡响。
硬件相关性：嵌入式软件和硬件绑定紧密。模块化可以把硬件抽象层（HAL）和业务逻辑分开，换芯片时只需要改 HAL 模块，业务代码不用动。

一句话总结： 模块化是手段，低耦合和高内聚是目标。三者共同作用，才能让嵌入式软件变得可维护、可测试、可移植。

1.5 一张图看懂三者关系

下面这张图展示了模块化、低耦合、高内聚在嵌入式架构中的位置和作用。我建议你把它存下来，每次做架构设计时对照一下。

1.6 一个简单的代码对比

光说不练假把式。咱们看两段代码，感受一下差距。

反面教材：高耦合、低内聚

// main.c - 所有功能揉在一起
int temperature = 0;
int heater_state = 0;

void read_sensor() {
    // 直接操作硬件寄存器
    temperature = *(volatile int*)0x40001000;
}

void control_heater() {
    if (temperature < 20) {
        // 直接操作 GPIO 寄存器
        *(volatile int*)0x40002000 = 1;
        heater_state = 1;
    }
}

void display() {
    // 直接操作 LCD 寄存器
    printf("Temp: %d\n", temperature);
}

int main() {
    while(1) {
        read_sensor();
        control_heater();
        display();
    }
}

正面教材：模块化、低耦合、高内聚

// sensor.h - 传感器模块接口
#ifndef SENSOR_H
#define SENSOR_H
int sensor_read_temperature(void);
#endif

// sensor.c - 传感器模块实现
#include "sensor.h"
int sensor_read_temperature(void) {
    // 封装硬件操作
    return *(volatile int*)0x40001000;
}

// heater.h - 加热器模块接口
#ifndef HEATER_H
#define HEATER_H
void heater_set_state(int state);
#endif

// heater.c - 加热器模块实现
#include "heater.h"
void heater_set_state(int state) {
    *(volatile int*)0x40002000 = state ? 1 : 0;
}

// display.h - 显示模块接口
#ifndef DISPLAY_H
#define DISPLAY_H
void display_temperature(int temp);
#endif

// display.c - 显示模块实现
#include "display.h"
void display_temperature(int temp) {
    printf("Temp: %d\n", temp);
}

// main.c - 业务逻辑
#include "sensor.h"
#include "heater.h"
#include "display.h"

int main() {
    while(1) {
        int temp = sensor_read_temperature();
        if (temp < 20) {
            heater_set_state(1);
        }
        display_temperature(temp);
    }
}

对比一下：

反面教材：改一个传感器，要动 main.c 里的所有函数；全局变量满天飞，测试时根本 mock 不了。
正面教材：每个模块独立编译，接口清晰。换传感器只需要改 sensor.c，其他模块完全不受影响。

我个人习惯，写代码之前先画模块图，把接口定义好，再动手写实现。这样虽然前期多花点时间，但后期维护省下的时间，十倍不止。