Temp不能跨扫描周期,也就是不能实现数据的连续轮转。
所以temp在一个扫描周期中的使用先后次序就很重要。这是一种耦合,由底层机制带来的用法上的耦合和限制。
随着一个FB或FC内部的结构越来越复杂,其内部会分成多个子模块。
如果一个Temp的使用范围超出一个子模块,在多个子模块中存在,那么这些子模块的组织顺序,就在某种意义上被锁定了,不能前后随意拖拽窜动。Static就没有这个问题。
例如:我先前开源的Modbus案例源码,其内部由17个子模块构成。这些子模块的位置组织和摆放,可以随意前后挪动,都不会有问题,唯独有一个子模块例外。
时间久了就不记得先前的程序细节。一查看才发现,其中用了Temp变量,就出现了上述的问题。
开销、便利与代价,相互之间是平衡的,就看自己想要什么。事物在时间中会变得复杂,贯彻一个原则并不容易。
为什么前后可以自由窜动很重要呢?是因为想要一个解耦的架构。
这样子模块可以随意修改扩展,而不会影响其它的。这样的子模块可以被称为一个层,也就是一个功能子集,其中的元素可以自由增删。
非常复杂的FB内部调度机制和结构设计,最后就会走到这一步。
那为什么不用很多独立封装的FB或FC嵌套组合而成一个大FB呢?因为我喜欢扁平化设计。
一个解耦的层,与一个独立的FB或FC在逻辑本质上是等价的,但开销更低,可以明显降低架构的复杂度,提高清晰度。这方面的实践效果对比都验证了这一点。
另外,用FB或FC组合出更大FB的想法,乍看是有道理。但当问题变得极度复杂和需求动态化后,这些组件FB或FC的处理会变得更复杂,接口需要不断调整和缠绕。
这时候你有可能会意识到一件事:先前你认为一个独立的局部,可以独立封装成一个FB和FC的。但在更复杂的局面下,这些独立FB和FC之间其实是更应该耦合的。而你先前的做法,只是因为当时的局面简单,就认为它们永远会彼此无关,就把这些局部元素解耦分开了,而其实这些元素在更复杂的局面下,本应就是内聚在一起的。