来源 | 工程师进阶笔记 在单片机固件开发圈子里面，有一个根深蒂固的观念：设计模式是面向对象语言的“炫技操作”，跟资源有限，逻辑直接的单片机根本不搭，压根扯不上边。 但架不住现在的物联网/新能源汽车/工业控制等领域的产品业务逻辑卷得越来越凶狠，单片机固件开发，早就不是当年那种“裸机循环走天下”的模式了。 多平台协同跨平台移植，这些已经成了常规操作，设计模式在单片机软件解耦和模块复用方面的优势，已经不断显现。 至于单片机固件开发，有没有必要用到设计模式，核心就一句话：看项目规模和需求，不要盲目跟风，也不要否定一刀切。 设计模式的最大特点是“软件解耦、模块复用、容易维护”，刚好戳中了传统单片机固件开发的弊端痛点， 以前的单片机工程师在写固件代码的时候，都喜欢走野路子，一上来就是“裸机循环+全局变量满天飞”，业务逻辑和硬件操作，耦合乱缠得像一团麻花，然后在后期维护或者迭代的时候，堪称“大型拆弹现场”。 不管是换单片机芯片，还是加一个小功能，或者是换一个硬件模块，都得去动核心代码，不仅费劲儿，还容易新增各种各样的bug。 然而，在使用了设计模式之后，相当于使用了现成的“标准化套路”，能在单片机有限的资源里面，把代码的架构和模块接口，捋的明明白白的。 有时候，大伙不必被“单片机资源有限”的固有认知绑住了手脚，单片机的RAM和ROM就这么点儿，过度设计确实会增加硬件负担，但根据实际的项目应用，选对轻量级的设计模式，反而能够反向优化资源。 比如单例模式，对于UART、SPI、IIC这些全局独一的硬件通信接口，使用单例模式可以锁死硬件外设的唯一初始化，防止多次重复，避免资源争抢的尴尬局面。 单例模式可以阅读这篇文章： 在遇到复杂场景的时候，比如多模块协同，使用观察者模式的订阅通知机制，可以完美实现事件解耦，新增模块也不用动原来的代码，直接拉满扩展性。 又比如，在适配不同传感器硬件的时候，工厂模式就能派上用场，新增传感器型号只需要修改扩展逻辑，上层的应用代码基本不用修改。 工厂模式可以阅读以下文章： 当然了，在编写单片机固件代码的时候，也别陷入了“为用而用”的怪圈，根据实际的项目需求进行选择才是王道，就像控制按键或LED这类小需求，几十行代码就能搞定，如果硬套设计模式，那纯属多此一举。 但是，如果是团队协作开发，要进行跨平台移植，或者是计划长期迭代的项目，那就建议使用设计模式，既能统一代码风格，减少开发者之间的沟通成本，又能屏蔽硬件差异，方便不同平台之间的移植。 关于C语言设计模式，可以阅读以下文章： 在单片机固件开发里面，设计模式并什么什么“花架子”，也没有必要过度“神化”，设计模式只是一种经过实战检验的工具经验，没有必要死磕语法进行堆砌。 就算是单片机C语言开发，使用结构体和函数指针这些特性，就能够把设计模式的核心思想应用起来。 关键还是需要守住“按需设计”的底线，小项目使用简单的模式就能搞定，大项目靠组合模式能搭建稳定的架构，在硬件性能、资源占用、可维护性之间，找到一个最优解。 总的来说，单片机不是不能用设计模式，而是不能盲目跟风乱套，等业务逻辑的复杂度上来了，设计模式所带来的各种优势，远比它所占用的那点硬件资源香得多。 让产品的软件从“能跑就行”升级到“好用易扩展”，这也是嵌入式软件工程师从入门到进阶的必备技能点之一！ -END-
