[特殊字符]️ 推荐你重点掌握的 5 个设计原则：构建可靠嵌入式软件架构的基础

在系统架构设计中，如果你希望做出“稳定、好维护、可复用”的系统，这五个原则值得你铭记于心。

我们将以简单语言 + 结构化图示，让你快速理解并上手。

---

1️⃣ 低耦合，高内聚

什么是“耦合”和“内聚”？

• 耦合（Coupling）：模块与模块之间的依赖程度。

• 内聚（Cohesion）：模块内部功能的相关性。

✅ 好的设计：

• 模块之间互不依赖，修改一个模块不会影响其它模块。

• 每个模块内部功能紧密相关，不杂乱。

示意图：

✗ 坏例子（高耦合）：

[模块A] <----> [模块B] <----> [模块C]
       ↑           ↓
     [模块D] <----> [模块E]

✓ 好例子（低耦合，高内聚）：

[模块A]   [模块B]   [模块C]
   ↓         ↓         ↓
 [驱动层] [通信层] [状态机层]

---

2️⃣ 分层解耦：结构清晰，职责分明

常见分层：

层级	职责示例
应用层	处理业务逻辑、AT命令
协议层	解析BLE、TCP等协议
状态机层	管理系统状态、响应事件
驱动层	控制硬件、调用外设API

好处：

• 层级分明，便于测试和替换。

• 每一层只处理自己该处理的事。

层级结构图：

[AT命令解析] ←→ [应用逻辑]
      ↓
 [BLE协议处理]
      ↓
 [状态机调度]
      ↓
 [蓝牙/串口驱动]

---

3️⃣ 单一职责原则（SRP）

定义：

一个模块、类、函数，只做一件事，并做好这一件事。

❌ 坏例子：

void handle_command_and_blink_led_and_parse_json(...) {
    // 太多职责混在一起
}

✅ 好例子：

void handle_at_command(...);
void control_led(...);
void parse_json(...);

---

4️⃣ 可测试、可扩展

思考这两点：

• 可测试：每个模块能单独测试？需要依赖别的模块才能跑吗？

• 可扩展：新增功能时，是否能不改动原有逻辑？

推荐方式：

• 使用接口、抽象层，例如定义 ble_driver_send() 而不是直接调用 hal_uart_send()。

• 使用事件队列、状态机来连接模块，而非硬编码逻辑链条。

---

5️⃣ 容错与稳定优先

原则：

在任何系统中，出错时能快速恢复，比追求极致性能更重要。

实现建议：

• 所有 API 返回值必须检查。

• 使用 Watchdog 保证系统挂掉能重启。

• 所有通信输入都必须校验合法性。

稳定策略图：

[串口接收] --> 校验格式 --> 入队列 --> 处理命令
                    ↓
               错误？立即丢弃 + 上报

---

✅ 总结

原则	核心目的
低耦合，高内聚	降低模块之间干扰
分层解耦	清晰结构，职责明确
单一职责原则	每个模块聚焦一个任务
可测试、可扩展	更容易维护和演进系统
容错与稳定优先	提高系统鲁棒性与可靠性

---

实践建议：

• 在做架构设计时，用画图、分层、抽象接口方式思考。

• 编写每个模块前，先写出职责说明。

• 系统上线前，重点测试边界条件、异常输入。