3.4 面向对象：把设备抽象成类

3.4 面向对象：把设备抽象成类

本节摘要：功能块天生就是类：声明是类定义，调用产生实例，实例数据就是对象状态。本节借建筑图纸的类比把类、实例、接口讲透，给出青线设备库的抽象过程与继承的克制用法——从IT转岗的读者会在这里找到老朋友，电气背景的读者会在这里打通新通路。

前三节把格子、容器、地址理清，本章收官这一节解决数据设计最高的那层楼：把"一台设备"封装成一个类。这节内容原属高阶章节，青线的实践证明它属于基础——设备抽象做得早，第4章的逻辑与第6章的诊断都直接受益。

类比着学：功能块是户型图

从建筑说起。一套户型图定义了房间布局：几室几厅、门开在哪、水电怎么走——图纸不是家，是造家的规则。拿同一张图纸在同一个小区盖三十套，每套是独立的房子，住着不同的人，水表电表各走各的。图纸与房子的关系，就是类与实例的关系。

功能块完全是这个结构。功能块声明定义了"一台电机该怎么管"：需要哪些输入（启动、停止、保护反馈）、产出哪些输出（运行、故障、电流）、内部记哪些状态（运行中、停止中、故障中）——这是图纸。程序里每写一次调用，系统就按图纸盖一套房子：一号输送电机调用一次、二号再调用一次，两台电机各自的运行状态、故障记忆互不串门——实例数据就是各家各户的水表电表。2.4节说"功能块是带记忆的容器"，现在可以说得更准确：功能块是类，调用产生实例，实例数据即对象状态。

青线设备库：一次抽象的全过程

青线全线约一百台执行设备：四十台电机（输送、泵、风机）、六十只阀（气动阀、灌装阀、比例阀）。抽象从"找共性"开始：把所有电机的控制需求摊在白板上比对，启保停是公共底座，热保护与故障复位是公共配件，差异只有个别设备要加运行小时统计或预热逻辑。于是电机类Motor_FB定稿：接口收七个输入出五个输出，内部状态机管好一切细节。

抽象的过程有一条黄金法则：接口为调用方设计，不为实现方方便。调用方（程序层）关心的是"让它转、知道它在转、知道它坏了"，因此接口里是启停指令与健康反馈；实现细节——去抖、自锁、保护联锁的先后——全部藏进内部。判断一个字段该不该进接口，就看程序层是否需要知道：需要，进接口；不需要，进内部。这条法则让全线四十台电机的调用代码长得一模一样，新工程师读主程序如同读设备清单。

阀门类的抽象遇到真分歧：气动开关阀有开到位与关到位双反馈，比例阀却是连续开度给定加模拟反馈，两者接口差异实质存在。青线的处理是克制地放弃合并——分成Valve_FB与AnalogValve_FB两个类，只把"故障、使能、复位"三个信号做成一致的接口约定，供上层联锁逻辑统一访问。硬把不同设备塞进同一个类，得到的是处处分支判断的伪通用，不如两个干净的类。接口一致与类一致是两件事：前者是语义约定，后者是代码复用——青线要前者，不苛求后者。

继承与多态：能不用则少用

IT背景的读者此刻多半在等继承与多态——PLC平台确实提供（扩展类、接口实现），但青线的态度是克制。原因有三。其一，维护受众：继承层级对电气背景的维护者是抽象税，一层扩展就要跨两个定义理解行为；其二，工具链支持：PLC生态的版本比对、在线监控对深层继承的显示支持远弱于文本IDE；其三，收益错位：软件里继承解决的是"大量同构类演进"问题，产线设备库的规模用"复制加接口一致"就能覆盖，收益撑不起成本。

青线留下的克制版遗产是接口约定的统一：不论电机还是阀门，故障、使能、复位三个信号的名字与语义全线一致，上层联锁功能块可以对任意设备"一视同仁"地写健康聚合逻辑。这是多态的实用主义版本——不追求语法层的多态机制，只保证语义层的调用一致性。用二成的心智成本拿到八成的收益，这笔账在产线场景里算得过。

设备类的接口清单：一张可以抄走的模板

把青线电机类与阀门类的接口合成一张通用模板，读者可以直接改造取用。电机类接口九个信号：使能、启动、停止、复位进；运行、故障、就绪、运行小时脉冲、当前状态码出。阀门类再分开关阀与调节阀两档：开关阀接口十一个信号（开令、关令、复位进；开到位、关到位、故障、动作中、状态码出，外加超时参数两个）；调节阀接口八个信号（开度给定、复位进；开度反馈、故障、状态码出，加死区与动作时限参数）。状态码统一枚举：停止、运行或全开、全关、动作中、故障——上层逻辑永远可以用同一把尺子读任何设备。

这张模板的深层价值在"参数也进接口"：动作时限、去抖时间不再是写死在块内部的常数，而是实例参数——同一张图纸盖出的房子，各户可以调自己的门锁灵敏度。参数化的思想在4.5节会以返工故事的形式再强调一次，此处先在接口层立好。

抽象的时点：早做还是晚做

设备抽象该在项目哪个阶段做？青线的答案是：数据设计期做接口（本章），实现期填内部（下一章），绝不到联调期才补。过早抽象的风险是没有真实调用者、接口想当然；过晚抽象的风险是逻辑已散落、抽象沦为表面文章。青线的做法是"接口先行、用例驱动"：数据设计周里，先写好程序层将来的调用清单——"全线四十台电机怎么调用"——再倒推接口形态。调用者说了算，是抽象不跑偏的定盘星。

调用侧的一课：实例命名的仪式感

抽象的另一端是调用，实例命名是调用侧最重要的仪式。青线的实例命名规则："站号加设备位号"（如W1_M03对应一号站三号电机），与IO表位号一致——这样实例名、位号、接线图页码三线合一，任何一条线上查到的名字都能滑到另外两条。实例数据块同样按此命名，诊断时从HMI报警一路点进实例内部，路径不用回忆。

反面教训也来自老项目：实例名随手的Motor1到Motor40，加上目录结构混乱，联调期"三号站五号电机"到底对应哪个实例成了每日谜题，后来靠交叉引用逐个重新对账。命名是抽象的落地形态——类设计得再干净，实例名一团糟，抽象的红利照样漏光。命名规则进编码规范、评审时当必查项，是青线用两周返工换来的条款。

本节要点回顾

• 图纸与房子：功能块声明是类，每次调用是实例，实例数据让四十台电机互不串门；
• 接口黄金法则：为调用方设计接口，实现细节藏内部，全线调用代码因此长得一样；
• 抽象宁拆勿挤：开关阀与比例阀分作两个类，保三个公共信号语义一致，胜过一个大杂烩类；
• 继承克制：产线规模用不上深层继承，接口约定的语义一致是性价比之选。

数据章节到此收官：类型、容器、地址、设备类，青线的家底全部立好。下一章开始真正的动作——在这副骨架上写逻辑。