26
回答
如何通过面向对象的方式实现通讯协议?
利用AWS快速构建适用于生产的无服务器应用程序,免费试用12个月>>>   

通讯协议通常是这样的:

<STX><STX><COMMAND>[<DATA><DATA>...]<CHKSUM><ETX>

 这里

<STX> 帧开始标志(比如0xF5);
<COMMAND> 命令类型(比如0x01表示读,0x02表示写,等等);
<DATA> 数据;
<CHKSUM> 校验码;
<ETX> 帧结束标志(比如0xFE)。

对于同一种协议,请求帧和返回帧就有很多种。比如

读命令1:
发送:<STX><STX><0x01><0x00><CHKSUM><ETX>
返回:<STX><STX><0x01><0x02><CHKSUM><ETX>
数据区返回的是byte(1个byte)


读命令2:
发送:<STX><STX><0x02><0x00><CHKSUM><ETX>
返回:<STX><STX><0x02><0x02><0x03><0x04><0x05><CHKSUM><ETX>
数据区返回的是int(4个byte)

由此,<COMMAND>定义不同,返回帧中<DATA>解析就不一样。

所以想问各位大神,如果以后要扩展<COMMAND>的类型,或者增加另外一种新的协议,怎么样的类设计能比较好的满足未来的扩展?

举报
共有26个答案 最后回答: 5年前

通信就是流 或者包

如果是流, 就需要分包

流/包不是对象

你偏要用对象, 如果要用对象, 你就随便设计一个, 看看有没有可能设计得比java或者C++的IO流更糟糕

这么多年了, 能够比它们设计得更糟糕的, 还没有见过.

谁见过更糟糕的, 不妨展示一下, 也开开眼界.

引用来自“宏哥”的答案

通信就是流 或者包

如果是流, 就需要分包

流/包不是对象

你偏要用对象, 如果要用对象, 你就随便设计一个, 看看有没有可能设计得比java或者C++的IO流更糟糕

这么多年了, 能够比它们设计得更糟糕的, 还没有见过.

谁见过更糟糕的, 不妨展示一下, 也开开眼界.

您讲的是流啊什么的,而我问的是协议的OO。

我不可能让客户端去了解整个协议的各种帧,然后去组装或者解析。客户端只需要告诉我,比如读电压,剩下的就由封装去做。

引用来自“纯天然原味酱”的答案

引用来自“宏哥”的答案

通信就是流 或者包

如果是流, 就需要分包

流/包不是对象

你偏要用对象, 如果要用对象, 你就随便设计一个, 看看有没有可能设计得比java或者C++的IO流更糟糕

这么多年了, 能够比它们设计得更糟糕的, 还没有见过.

谁见过更糟糕的, 不妨展示一下, 也开开眼界.

您讲的是流啊什么的,而我问的是协议的OO。

我不可能让客户端去了解整个协议的各种帧,然后去组装或者解析。客户端只需要告诉我,比如读电压,剩下的就由封装去做。

协议去搞OO

我就告诉你,你老板错了, 他找错人了.

引用来自“Mallon”的答案

不要用二进制结构,而是采用一种结构化的文本格式,例如Json、XML

我没讲清楚。您所说的更倾向于上层。

我的比较低端,串口通讯。上层应用要和串口设备通讯。

引用来自“宏哥”的答案

引用来自“纯天然原味酱”的答案

引用来自“宏哥”的答案

通信就是流 或者包

如果是流, 就需要分包

流/包不是对象

你偏要用对象, 如果要用对象, 你就随便设计一个, 看看有没有可能设计得比java或者C++的IO流更糟糕

这么多年了, 能够比它们设计得更糟糕的, 还没有见过.

谁见过更糟糕的, 不妨展示一下, 也开开眼界.

您讲的是流啊什么的,而我问的是协议的OO。

我不可能让客户端去了解整个协议的各种帧,然后去组装或者解析。客户端只需要告诉我,比如读电压,剩下的就由封装去做。

协议去搞OO

我就告诉你,你老板错了, 他找错人了.

我没讲清楚,抱歉。

您所说的更倾向基础,没错,底层就是字节流,没什么好OO的。

我的比较低端,串口通讯。上层应用要和串口设备通讯。上层应用这一块,封装和串口设备通讯细节,完全可以在通过帧的功能来处理各种分支,在每个分支里实现串口设备的各种请求帧返回帧,无非就是switch或者if。

我只所以要问OO的方式,是因为如果串口硬件升级(新的帧格式),或者增加了新的硬件(新的协议),导致我的上层的分支特别庞大,扩展困难。你完全可以想像,<COMMAND>数据位不同,字节数不同,可能有上百种帧结构。

和我现在做的一样···我也在定这种通信协议,不过没有你想得这么技术化,我的想法就是,16或32字节通信,指令合理的应用上每一个字节就好了,至于你说的OO,那是收到指令协议后,程序员做的,不是在做指令的时候考虑的吧,我个人认为。当然你的指令定得好些,写代码无论是量还是难度都要小些而已,呵呵·····个人意见,不知对错!

引用来自“纯天然原味酱”的答案

引用来自“宏哥”的答案

引用来自“纯天然原味酱”的答案

引用来自“宏哥”的答案

通信就是流 或者包

如果是流, 就需要分包

流/包不是对象

你偏要用对象, 如果要用对象, 你就随便设计一个, 看看有没有可能设计得比java或者C++的IO流更糟糕

这么多年了, 能够比它们设计得更糟糕的, 还没有见过.

谁见过更糟糕的, 不妨展示一下, 也开开眼界.

您讲的是流啊什么的,而我问的是协议的OO。

我不可能让客户端去了解整个协议的各种帧,然后去组装或者解析。客户端只需要告诉我,比如读电压,剩下的就由封装去做。

协议去搞OO

我就告诉你,你老板错了, 他找错人了.

我没讲清楚,抱歉。

您所说的更倾向基础,没错,底层就是字节流,没什么好OO的。

我的比较低端,串口通讯。上层应用要和串口设备通讯。上层应用这一块,封装和串口设备通讯细节,完全可以在通过帧的功能来处理各种分支,在每个分支里实现串口设备的各种请求帧返回帧,无非就是switch或者if。

我只所以要问OO的方式,是因为如果串口硬件升级(新的帧格式),或者增加了新的硬件(新的协议),导致我的上层的分支特别庞大,扩展困难。你完全可以想像,<COMMAND>数据位不同,字节数不同,可能有上百种帧结构。

function protocol_process(){

}

function future_protocol_process(){

if ( hostory){

protocol_process();

esle{
new_protocol_process()

}

}

}

这样明白了没有, 这件事就是报文定义, 解析,和OO没有什么关系. 看看伪代码就知道了.

--- 共有 1 条评论 ---
纯天然原味酱目前就是用类似的方法做的。 5年前 回复

引用来自“纯天然原味酱”的答案

引用来自“Mallon”的答案

不要用二进制结构,而是采用一种结构化的文本格式,例如Json、XML

我没讲清楚。您所说的更倾向于上层。

我的比较低端,串口通讯。上层应用要和串口设备通讯。

呵呵知道,底层一样可以用文本格式,我们现在已经开始这样做了,你可以 一试,比如C语言的cJSON库,Python内置的Json解析
顶部