项目心得：在嵌入式系统中进行函数设计时可以这样处理！

最近在做一个网关项目，分享一下在设计模块的接口时的一个小心得。

网络通信少不了对数据的处理，举个例子，下行的网关发给设备的某类消息中的数据格式如下：

这是json格式的数据，还有很多发下来的消息也是json格式的，因此需要一个json模块来专门进行数据解析以及组json格式的包。可以从网上下载针对嵌入式的小型json模块直接移植过来，但这里考虑到数据协议并不复杂，嵌套层数不多，最多也就两层，所以自己写算了。

首先需要设计解析json数据的接口，该设计成什么样？请看下面两种方法。

方法一 

定义一个结构体：

定义数据处理函数如下：

输入：要处理的数据data，数据长度len

处理：把数据中的一项一项的值解析出来存到结构体outdata中对应的元素中去

输出：outdata；

返回：0（正常）/-1（异常）；

比如上述数据，输出：

方法二 

定义数据处理函数如下：

输入：要处理的数据data及其长度len，要从json数据中获取内容的属性名称 attribute；

输出：属性的值value；

处理：从数据data中获取attibute的值，赋给value；

返回：0/-1.

比如，输入上面数据赋给data，attribute="msg"，输出value="DEVICE_CONTROL"

总结

上面两种方法哪种方法更好？乍一看，方法一好像很好，很省心对吧？你只需要输入数据，在里面处理一番，输出的东西都给你弄好了。但是，仔细想想，这个函数里面会怎么实现呢？第一步是从data中去获取"msg"属性的值，赋值给结构体中的type，第二步是从data中获取”id”属性的值赋给结构体中id，这不就是方法二函数在做的事情吗？所以方法一里面还是要调用方法二中函数的，方法一并没有把最小单位的重复动作设计成一个函数。

       

另一方面，方法一中直接把数据中的各属性输出到结构体，实际上是杂糅了业务相关的东西在里面，也就是说，如果换一个项目，仍然有json数据要处理，但是属性名字不是这些，而是其他命名的，那么方法一中的函数就不能直接复用移植，方法一并不是纯处理json格式数据的函数，杂糅了具体项目业务的协议在里面了，不够纯粹。方法一中函数适合放在具体业务处理的模块里面，方法二中函数才是json模块函数，可移植性比较好。

另外在进行模块设计时，有一个原则是“高内聚，低耦合”，显然如果方法一中的函数放到json模块中去，那就不够内聚了，与业务模块有一些耦合了。

1.8位MCU，你还好吗？

2.打算跳槽的嵌友，这家公司在招人！

3.“氦气技术”为最小嵌入式设备提供强大处理能力！

4.电路出现问题，你能一眼看出哪的原因吗？

5.准备开发一个智能硬件，得先看这篇文章！

6.2019年第2期《单片机与嵌入式系统应用》电子刊新鲜出炉！