嵌入式开发中需要用到设计模式吗?

工作有些年了，每每看到一些朋友会问，设计模式需要学吗？好像做嵌入式的从没遇到过需要用设计模式的，所以一直没系统学习，但是我也知道这个很重要，久而久之，到头来还是没学。

这里我说一下自己的看法和思考，来看看一些问题。

什么是设计模式？

设计模式是代表了开发人员不断积累的最佳的实践，是软件开发人员在软件开发过程中面临的一般问题的最优解决方案。

也就是说，经过了不断的发展，不同的问题或者方案有对应的一套法子，而这个法子被总结成了这么几十种通用模式，我们如果遇到了就对应着去套用就可以了。

当然那几大开发原则和二十几种设计模式大家还是随便去找都可以找到说明的，笔者就不多说了（我也只用到了其中几种），大家自行学习为好。

开发中为什么很少用设计模式？

在平时项目开发中，我们很少使用设计模式，我感觉这个现象还是很正常的，不是说工作中没用到设计模式，而是大多数情况下我们项目中没想那么多，更多的是做一些需求更改，而忽略本质。

设计模式的目的是提供可拓展性和可维护性，但是我们开发的项目本身，大部分都是固定写死的，逻辑单一，我们开发的模块也并不在其他的位置或项目中复用，目的很明确就是做当前的业务。

平时开发中用到设计模式的地方很少，但是框架就不同的了，框架必须适应不同的项目，具备高弹性和拓展性。他们要能适应各种不同的环境，所以，设计模式在框架设计中处处可见。

假如一开始在大公司或者接手一个接近成熟的项目时，那大概率会负责一些小模块或者细分领域的开发；而在小公司或者是几乎从零开始做项目的时候，可能我们本身还不够去设计一个符合项目长期规划的架构，最终导致写的代码比较乱，维护性差。

所以在嵌入式开发中，当我们有了一定的基础和项目经验的时候，我们就会想着，嗯，一个好的架构多么重要啊，或者我需要去好好学一下设计模式了。

嵌入式开发一定要学设计模式吗 ?

可以这么说，设计模式为拓展而生。

平时项目中的业务逻辑代码，大部分功能是死的，是专为这个场景而生的，不会在另外的场景中出现，这种业务的开发，是不需要设计模式的。

但是如果需求有变化，我们一般可能就直接修改源代码了，这样实际上带来了一定的修改成本，而为了一个项目中可能不明确的未来变化，而精心设计扩展性很高的架构，成本也是显而易见的，所以，这是一个取舍。

当然，从长期来看，一个好的设计是值得的，毕竟与其不断的修改新的需求，还不如一劳永逸，这样开发人员才能从各个方面高效去开发了。

在嵌入式软件开发中，当软件系统到达一定的复杂程度时，设计模式就显得尤为重要。虽然搞嵌入式的常常是基于一些16位/32位/64位单片机开发，而且这些可能受一些硬件方面的限制，但是单片机软件也是可以遵循软件工程的基本原则来进行架构的。

从代码组织的角度比如组件化、分层、去耦等等，或者从设计角度比如基于消息队列、事件驱动等等，都是有因可循的。

所以对于这个问题，嵌入式开发最好是要学设计模式，这里鼓励大家多看看重构、设计模式、面向对象的C等方面的书籍。

设计模式该怎么学？

前面说了那么多，设计模式是什么，嵌入式中哪里用到了设计模式，设计模式到底需不需要学等等，好，那你告诉我到底怎么学！

这里我想分一些情况来说，关于这个问题，设计模式怎么学习，得看你的程度、你主要解决什么问题、你负责的部分而定。

若你的编程水平或者学习的程度还没到那（还在学习怎么编程阶段），看了自然是懵逼的，这个时候还是好好补补基础知识，这些还用不到。

若在项目当中，你解决的大部分是一些业务逻辑，这种情况能用的设计模式不多，因为需要的是业务模式，也就是参考设计模式原理，自己设计业务模式改改需求啥的，就没必要了。

若你负责或参与应用框架或与其相关，那帮助就大了，这个时候用什么设计模式，怎么去设计就要考验功底了。

当然，不管怎么说，只要有时间即使是你目前程度还不到，你也可以学习设计模式使自己提升程度，但得一步一步来，稳中进步。

这个学习也不是一次性把所有的都学习了，这样其实也很难掌握，可能只是知其表而已，一般先从某个与你要处理的问题相关或者常会遇到的模式开始学起，一次学一个，学的深一些。

大部分人最常提的是单例、工厂、策略这几个，比如一个功能，要求既要支持串口通信，又要支持TCP通信，而对调用方来说最好不要知道它们的区别，这就是典型的策略模式场景。

这种比较常见的情况，很多项目中都可能遇到，因此不可能不学，网上也有很多经验分享，还有很多教程例子，这个时候也不可能学不会。

总结

到此，你觉得设计模式有没有用？

每个人的情况不同，学习过程不一定是这样，做的工作内容肯定也不一样，关键点是只要你在这行，在写代码，那么一般一定用得到其中几个模式，等你学会几个，并且常用，时间久了自然就明白了。