结构化文本OOP中Properties与VAR_IN_OUT的区别及适用场景

一、本质差异 #

1. 数据归属与存储 #

• Properties（搭配私有VAR）：数据（比如示例里的Name_）是FB实例的私有状态，存储在FB自身的内存空间中。外部只能通过属性的getter/setter间接读写，FB完全掌控这个值的生命周期和读写规则。
• VAR_IN_OUT：Name是外部变量的引用，FB自身不存储该值，仅借用外部存储位置。读写操作直接作用于外部变量，FB对数据无所有权，本质是“替外部操作变量”。

2. 逻辑封装能力 #

• Properties：即使当前是简单赋值，后续也能给getter/setter添加业务逻辑——比如设置设备名称时校验长度、读取时自动转大写；还可设置为只读（仅实现getter）或只写（仅实现setter），权限控制灵活。
• VAR_IN_OUT：无任何封装能力，外部变量直接暴露给FB，读写均为硬操作，无法在FB内部做拦截或处理，且必须同时支持读写，不能单独限制方向。

3. 实例独立性 #

• Properties：每个FB实例的私有变量相互独立，甲设备修改名称不会影响乙设备的名称。
• VAR_IN_OUT：若多个FB实例绑定同一个外部变量，一个实例修改后，其他实例读取的会是修改后的值，相当于共享数据。

二、适用场景 #

优先选Properties（带VAR）的情况 #

• 属性是FB的固有内部状态：比如设备的名称、运行状态、累计运行时长，这些属于设备自身的属性，应由FB自主维护。
• 需要给读写过程添加逻辑：比如设置参数时校验合法性、读取时计算动态值（如剩余电量=总电量-已用电量）。
• 遵循OOP封装原则：隐藏内部实现细节，仅对外暴露统一接口。

优先选VAR_IN_OUT的情况 #

• FB仅作为“数据操作工具”：不需要自身存储数据，仅帮外部处理变量。比如字符串拼接FB，直接操作外部目标字符串，无需自己保存副本。
• 处理大尺寸数据：比如大数组、复杂结构体，用VAR_IN_OUT可避免内存拷贝，提升性能。
• 无状态纯操作类FB：每次执行仅处理外部传入的数据，无需保留上次执行的状态。

一、核心不同 #

1. 读写时机控制 #

• 只读属性（仅getter）：外部可随时读取，不受FB执行周期限制。比如随时查询设备当前温度，访问属性时才触发getter逻辑。

• VAR_OUTPUT：仅在FB执行完成后，输出值才会更新到外部变量。比如数据转换FB，必须等执行完成，才能拿到转换后的结果，输出是FB主动推送的。

• 只写属性（仅setter）：外部可随时设置，设置后立即生效（若setter有逻辑则同步执行）。比如给设备设置新采样频率，设置后设备立刻按新频率工作。

• VAR_INPUT：FB执行前会先对输入值做“快照”，执行过程中即使外部修改输入，也不会影响本次执行结果。比如PID控制器，当前周期使用的是执行前的设定值，中途修改要等下一个周期才生效。

2. 扩展能力 #

• 属性（getter/setter）：可实现动态逻辑，比如只读属性无需存储实际值，每次读取时实时计算（如运行时长=当前时间-启动时间）；只写属性可在设置时触发关联操作（如设置报警阈值同时开启报警功能）。
• VAR_INPUT/VAR_OUTPUT：仅做纯数据传递，无法添加任何额外逻辑，输入输出为简单的变量拷贝或底层引用。

二、适用场景 #

只读属性 vs VAR_OUTPUT #

• 用只读属性：需要外部随时获取FB的实时状态，或返回动态计算值。比如设备的在线状态（由内部多个状态位判断）、实时电流（多传感器数据平均值）。
• 用VAR_OUTPUT：输出是FB执行的“结果”，仅在执行完成后有意义。比如排序FB，输入乱序数组，执行完成后输出排序后的结果。

只写属性 vs VAR_INPUT #

• 用只写属性：需要外部随时更新FB配置，且更新后立即生效。比如给设备设置新通信地址，设置后设备马上用新地址连接服务器。
• 用VAR_INPUT：FB执行依赖固定初始值，执行过程中无需变更。比如加法运算FB，输入两个数后，本次执行就用这两个数计算，中途修改输入不影响当前结果。

内容的提问来源于stack exchange，提问作者drl