前言
在完成航班配载系统初次实验后，我自认为已经掌握面向对象程序设计的基础思路，然而数字电路逻辑仿真系统实验，让我对软件架构设计产生了全新、系统的认知。
本次实验区别于前次对现实物理载体的简单建模与数值计算，核心任务为解析结构化文本输入，在内存中构建完整电路拓扑模型。系统需要兼容多种基础逻辑门，包含与门、或门、非门，同时支持多路选择器、译码器等具备多输入、多输出端口的复合功能器件，最终按照信号依赖关系逐级求解全部引脚电平并规范输出运算结果。
两次实验存在明显的设计层级差异：航班配载系统偏向具象实体建模，仅需对客观实物封装属性与计算逻辑；数字电路仿真系统则要求对硬件电路信号传递关系进行抽象建模。开发全过程分为多个迭代阶段：初期采用数组容器存储器件数据，存在查询效率低下、电路构建逻辑臃肿等问题；后续更换哈希映射结构管理电路节点以优化查找性能；初始线性遍历计算会出现信号时序错乱问题，通过引入基于入度的广度优先拓扑排序解决信号依赖运算顺序；依托抽象类、继承与运行时多态机制完成基础门电路向复合芯片的功能拓展。整个开发过程不只是代码编写实践，更是对面向对象三大核心特性综合实践，让我形成了更为规范化的软件设计思维。
一、核心知识点梳理与实践应用
（一）继承与多态：通过抽象层统一规范器件行为
抽象基类
项目开发初期，我曾考虑为每一类逻辑器件独立编写完整实体类，不抽取公共父类。但编码过程中发现，所有门电路、复合芯片存在大量共用属性：唯一器件编号、拓扑排序所需入度值、控制引脚集合、数据输入引脚集合、输出引脚集合、下游关联器件列表。若在每个子类中重复定义上述成员变量，会造成大量代码冗余，后期维护、新增器件的成本大幅提升。
基于该问题，我设计两个顶层抽象类：CircuitElement 电路器件基类、Pin 引脚基类。在CircuitElement中封装全部器件通用属性，同时定义抽象计算方法public abstract void Calculate()。该抽象方法强制所有子类独立实现自身信号运算规则，形成统一调用标准。后续新增多路选择器、译码器等器件时，无需修改顶层调度核心代码，仅新建子类继承抽象基类并重写计算逻辑即可完成功能拓展，直观体现软件设计开闭原则，即对功能扩展开放、对原有核心代码修改关闭。
运行时多态降低模块耦合度
多态机制是电路调度模块的核心支撑。拓扑排序的主循环逻辑如下：

while (!queue.isEmpty()) {
CircuitElement element = queue.poll();
element.Calculate();
// 更新后继器件入度、传递输出电平
}
队列中存储的数据类型统一为抽象父类引用，但程序运行阶段，虚拟机会自动识别引用指向的具体器件子类对象，执行对应器件独有的计算逻辑。调度模块无需区分当前处理对象是基础逻辑门还是复合芯片，仅需按照拓扑序列依次触发计算流程。调度逻辑与各类器件的运算逻辑完全解耦，模块边界清晰，代码可维护性显著提升。
（二）数据结构选型：基于业务场景选择容器
哈希映射替代线性列表优化查询效率
项目首个版本采用ArrayList存储全部电路器件。解析连线关系时，若需要根据器件编号查找上游信号源，必须遍历整个列表完成匹配，查询时间复杂度为 O (N)。小规模输入下性能差异不明显，当电路器件数量增多、连线关系复杂时，反复遍历会造成程序运行卡顿。
重构阶段将器件存储容器更换为HashMap<String, CircuitElement>，以器件唯一编号作为键、器件实例作为值存储。通过get()方法可直接根据编号定位目标器件，单次查询时间复杂度降至 O (1)，不仅解决运行效率问题，器件关联构建的代码逻辑也更加简洁清晰。
有序 TreeMap 保障位运算引脚顺序稳定
多路选择器、译码器等复合器件的输出索引由输入引脚电平组合转换为二进制数值得到，引脚排列顺序会直接影响位运算结果。开发初期使用无序 HashMap 存储输入引脚，容器遍历顺序随机，相同输入条件下多次运行会产生不一致的电平输出，调试难度极大。
后续将所有参与位运算的引脚集合替换为TreeMap<Integer, InputPin>，该容器底层基于红黑树实现，会自动按照引脚编号升序排列。通过new ArrayList<>(inputlist.values())获取引脚集合时，引脚始终按 0、1、2…… 有序排列，位运算的数值计算逻辑能够保持稳定，彻底解决输出结果随机错乱的问题。
（三）图论算法：拓扑排序处理信号依赖计算时序
数字电路的图模型抽象
组合逻辑电路不存在反馈回路，器件输出端口连接另一器件输入端口的信号传递关系，可抽象为一张有向无环图（DAG）。电路运算存在严格先后依赖：某器件所有上游输入信号完成计算后，才能执行自身电平求解。若按照随机顺序遍历计算，未赋值的输入引脚会读取空值，运算结果完全失效。
基于入度的 BFS 拓扑排序落地流程
为规范信号计算顺序，采用统计节点入度的广度优先拓扑排序算法，完整流程分为三步：
（1）统一统计入度：文本解析、完整构建电路拓扑后，批量遍历所有器件，统计每个器件输入引脚、控制引脚对应的上游信号源数量，数值即为当前节点入度；
（2）初始化待计算队列：将入度为 0 的器件（仅外接外部输入信号，无前置依赖）存入队列；
（3）逐级传递信号：从队列取出器件执行电平计算，遍历其所有下游关联器件，将当前器件输出电平赋值给对应输入引脚，下游器件入度自减 1；若入度归零，代表全部输入信号就绪，加入队列等待运算。
该算法能够保证任意器件仅在全部前置信号计算完成后执行运算，是整个仿真系统的核心调度逻辑。
（四）文本输入解析：正则表达式标准化格式匹配
结构化文本的正则匹配解析规则
实验给定输入文本格式复杂度较高，例如标识A(2)12-1代表 2 输入端与门、器件编号 12、当前连线对接器件 1 号引脚。若依靠字符串分割、多层条件判断拆分字段，代码分支繁多、可读性差。最终采用正则表达式统一匹配全部器件标识：
String pattern = "([AONXYMSZF])(\(\d+\))?(\d+)\-(\d+)";
借助Pattern与Matcher类分组捕获，一次性提取器件类型、输入端口数量、器件编号、目标引脚编号四类关键信息，大幅简化解析分支逻辑。
预创建占位节点避免拓扑图断裂
解析连线关系时存在时序问题：连线语句会提前引用尚未定义的上游器件，直接读取映射表会返回空对象，造成电路拓扑断裂。为维持图结构完整性，增加防御性处理逻辑：
CircuitElement source = elementmap.get(elementid);
if (source == null) {
source = createElement(elementType, elementid, K);
if (source != null)
elementmap.put(elementid, source);
}
当引用的上游器件未完成定义时，先初始化空白器件实例存入映射表作为占位节点，保证电路连线关系完整；拓扑排序阶段空白节点因无有效输入信号，会自然完成兼容处理，不会中断整体运算流程。
二、实验题量与整体难度分析
本次实验综合难度、开发工作量远高于航班配载实验。仅梳理多路选择器、译码器的真值表规则、引脚定义规范就需要花费大量时间，完整开发调试总时长超过十小时，调试占用绝大多数时间。电路信号具备级联传递特性，单个引脚计算出错会导致下游全部器件电平异常，仅通过输出结果无法快速定位故障点，需要逐行对照真值表排查每一级运算逻辑，调试流程繁琐。
本次开发深刻印证软件项目前期架构设计的重要性。若开发初期未抽象顶层器件父类、未区分控制引脚与数据输入引脚，后期拓展复合芯片时，原有底层存储、调度代码几乎需要全部重构。本次实验完成了硬件电路逻辑向面向对象图模型的完整转化，同时掌握依托图论算法解决业务依赖时序问题的设计思路。
三、系统架构设计迭代分析
阶段一：线性列表存储的初步开发版本
首个开发版本缺少系统化图模型设计，统一使用ArrayList存储全部器件，存在多处设计缺陷：
运行性能不足：电路连线较多时，根据编号查找上游器件需要线性遍历容器，运行效率偏低；
引脚分类缺失：所有引脚统一存入单一列表，未区分控制引脚、数据输入引脚、输出引脚，无法适配多路选择器等控制端与数据端分离的复合器件；
多态机制利用不足：虽然搭建了基础继承结构，但计算方法内存在大量硬编码逻辑，信号传递耦合严重，新增器件的拓展成本极高。
阶段二：重构后哈希映射 + 拓扑排序标准化架构
针对初版架构缺陷完成全量重构，从数据存储、调度算法、运算逻辑三方面优化：
存储容器全面升级
采用 HashMap 管理全局器件，解决编号查询效率问题；引脚集合统一拆分控制引脚、输入引脚、输出引脚三类，全部使用 TreeMap 有序存储，同时兼容基础逻辑门与多端口复合芯片的存储需求。
拓扑排序作为统一调度核心
封装独立拓扑排序计算模块，标准化信号运算时序。新增任意类型器件时，仅需实现自身计算抽象方法，无需改动调度流程，系统拓展性大幅提升。
位运算简化复合器件逻辑
多路选择器电平求解通过位运算简化分支判断，核心实现逻辑如下：
int idx = 0;
for (int i = 0; i < ipcount; i++)
if (inputs.get(i).level)
idx |= (1 << i);
for (int i = 0; i < (1 << ipcount); i++)
oplist.put(startOut + i, new Outpin(startOut + i, i != idx));
读取控制引脚电平组合转换为十进制索引值，仅索引匹配的输出引脚输出低电平，其余引脚统一输出高电平，将硬件真值表转化为简洁位运算逻辑，减少多层 if 分支。
分层输出打印模块
独立封装打印输出模块，通过类型判断对不同器件分组输出，组内按照器件编号升序排列打印内容。当前分支判断逻辑仍存在优化空间，但可稳定完成实验要求的输出规范。
四、开发过程典型问题与解决思路
多轮迭代开发中遇到大量典型程序设计、算法适配问题，整理四类影响最大的故障与对应解决方案：
无序容器导致位运算结果不稳定
初期使用 HashMap 存储输入引脚，容器遍历顺序不固定，控制引脚电平拼接得到的索引数值随机，输出结果每次运行均不相同。更换 TreeMap 有序容器后，引脚按照编号升序读 取，位运算输入顺序固定，运算结果完全稳定。后续涉及二进制权重计算的业务场景，均优先选用有序映射容器。
空指针异常导致程序中断
拓扑排序传递电平阶段，若上游器件未完成计算、引脚未赋值，直接读取电平属性会触发空指针异常，程序直接终止。在所有信号赋值位置增加空值校验逻辑：
if (op != null) {
i.level = op.level;
}
同时规范子类计算逻辑，输入信号缺失时向输出集合存入空对象占位，通过防御性判断规避跨模块调用空指针故障，提升程序运行稳定性。
入度重复统计引发死锁
最初设计在解析单条连线时直接累加目标器件入度，若一个上游器件连接目标器件多个引脚，会重复统计入度数值，器件入度无法归零，永远无法进入运算队列，程序陷入阻塞。修改统计逻辑，待完整电路拓扑构建完成后，全局统一遍历统计全部器件入度，彻底消除重复计数问题。
过度依赖类型判断造成代码冗余
初版代码频繁使用instanceof判断器件类型，业务逻辑与具体实现高度耦合。重构后将全部器件运算行为下沉至子类重写的抽象方法，顶层调度模块仅调用统一抽象接口，实现依赖抽象、不依赖具体实现的设计规范，降低模块耦合。