解耦为不同的模块,还是在一个模块内部解耦,是一个并不显而易见的选择。
正如CPU指令集的CISC与RISC,操作系统内核设计的宏内核与微内核。现实情况是,选择复杂设计的性能占上风,选择直接模块解耦的都不太能打,而很多人都认为直接模块解耦更好。这其中道理复杂,不是三言两语说清。但问题的本质就在于:定义固定接口、数据分隔、上下文关联。简单情景没问题,但是随着复杂和动态,事情变得并非想当然,负面凸显。
在PLC中,以先前的Modbus开源案例为例子,我选择的是:首先高内聚为一个单一模块,然后在模块内部去分解为四个部分,每一个部分内部再分解成数量不等的层,层由元素组成。
这四个部分是:UI、调度、IO公共管理、IO。
这个四部分的逻辑划分,适用于任意行业应用任意案例的模块。不论是底层的设备模块,还是顶层的工厂或生产线模块。
下面是这个具体案例内部的分层解耦情况。目前四个部分有很多层(12 + 5 + 2 + 9)。这些分层,与以前的开源案例代码相比,做了进一步的提纯归并,添加了一些辅助元素,以求更清晰和便于诊断。其中带有星号的层,是说如果把这个模块改写为其它任意串口Modbus设备,需要改动内容的层。