TTCN3新执行器系列-端口操作的接口简单化重构

08年做ttcn3转换器的时候，最烦人的工作就是做端口操作的模块。
其实端口操作也就send、receive、trigger和check语义，其他过程调用的操作我们已经不打算做的了。

 

下面是send语法：
Port "." send "(" TemplateInstance ")"
[ to ( AddressRef | AddressRefList | all component ) ]

 

下面是receive语法：
( Port | any port ) "." receive
[ "(" TemplateInstance ")" ]
[ from AddressRef ]
[ "->" [ value VariableRef ]
[ sender VariableRef ] ]

 

下面是trigger语法：
( Port | any port ) "." receive
[ "(" TemplateInstance ")" ]
[ from AddressRef ]
[ "->" [ value VariableRef ]
[ sender VariableRef ] ]

 

下面是check语法：
( Port | any port ) "." check
[ "("
( PortReceiveOp | PortGetCallOp | PortGetReplyOp | PortCatchOp ) |
( [ from AddressRef ] [ "->" value VariableRef ][ sender VariableRef ] )
")" ]

可以看到，参数还是挺多的，而且大部分参数是可选的。

刚开始的时候，导师已经做了一个模型，定义了不少的接口，然后后续工作让我补充。
以receive操作为例吧，接口就挺多的，譬如：
port.receive;
port.receive(a);
port.receive(a) from b;
port.receive(a) -> value c;
port.receive(a) from b -> value c
port.receive(a) from b ->value c sender d;

 

更麻烦的是，由于a在语法上是templateisntance，所以值、模板、模板变量都适合。
于是后续接口使用了c++的模板功能，而且大量使用了模板特化的东西。

 

就这样，噩梦开始了，receive接口从6变成18个，而且操作内部逻辑复杂，导致文件代码行膨胀厉害！
当时，一个receive逻辑文件就几千行的代码，冗余重复严重。

 

ok，有人会说接口简单化，但当时没有做，很大一部分原因是受限于转换器功能。
简单点说，转换器是基于antlr语法树实现的，转换过程中是一次读取操作，没有多次遍历语法树。
所以，转换一个语句前面部分内容时，就不清楚后面部分内容。
如果转换一个语句进行多次遍历，把信息都提取出来再转换，相信是ok的，但转换时间会翻倍以上。

 

现在回过头看，这里存在的问题主要有：
1、压根不应该使用c++的模板。
对于有类型继承关系的东西，完全可以使用基类+多态方式实现，c++的模板只会把事情做复杂。
2、接口应该统一简单化，将参数封装，减少代码冗余重复。

 

下面重点说说第二个问题是如何解决的。
首先，对receive操作来说，不需要区分没有接收值的情况，建议用null代替；
其次，from+value+sender是可选参数，可组合出多种形态，完全可以封装成一个参数（如struct结构）。
于是，现在变成唯一的带两个参数的receive接口，统一而简单！
port.receive(x,y); //y是from+value+sender的复杂结构

 

由于c的struct不支持参数直接赋值方式，我们还有两个选择：
1、使用类的构造函数方式实现；//会导致构造、赋值、析构等调用
2、使用函数返回值方式实现；//会导致赋值等调用

基于效率考虑，建议采用方法二，如下：
port.receive(x,makeparam(from,value,sender)); //makeparam返回封装struct结构

 

经过上述重构后，receive操作的代码量能减少80%以上，对后续维护非常有利。