数字电路模拟程序作业4-6三次迭代作业总结

一、前言
本阶段完成了三次航空器配载与货运管理系统作业，从基础的单舱货物装载业务落地，升级至多货舱分区存放的调度管理，最终延伸至航空器重心配平的物理运算校验，层层递进还原民航货运配载真实业务流程。整套系列作业依托真实行业业务场景设计，将面向对象编程的各类核心知识点融入功能迭代之中，在持续的功能拓展与代码优化里完成理论知识的实战落地。
作业4作为项目初始基础版本，重点围绕面向对象入门核心知识点展开考察，需要熟练掌握类与对象的定义方式、构造方法的重载使用、成员变量私有化封装、单一职责设计原则，同时结合基础数组操作、手动编码实现选择排序算法、控制台数据录入与标准化格式化输出等实操内容。本次作业需要设计五类核心代码结构，分别对应货物信息存储、航班基础信息维护、配载单据记录、货物排序处理以及程序入口调度，整体有效代码篇幅较短，开发难度偏向中等偏易，训练核心在于建立类职责划分的编程思维，依托单一职责原则拆分业务功能，同时脱离工具类排序方法，自主完成选择排序逻辑的编码实现，夯实基础算法编码能力。
作业5在初代版本稳定可用的代码架构之上做业务横向拓展，引入多货舱分区装载的业务场景，重点考察类与类之间聚合、组合两种关联关系的辨析与落地使用，新增二维坐标位置定位管理、不同货舱独立额定载重约束、货物按重量降序排序后依次分配装载的调度逻辑，同时需要完善装载结果判定逻辑，针对超重、舱位不足等场景给出对应的运行提示信息。本次作业在原有类结构基础上进行扩充，整体设计七类业务代码，新增仓位位置、货舱容器、输入合法性校验相关类，整体代码规模实现翻倍提升，开发难度处于中等水平。本次开发的核心难点在于精准区分聚合与组合的语义差异，合理设计航班、货舱、货物三者之间的关联结构，同时完成多货舱场景下的货物自动分配、剩余载重实时计算、装载失败异常场景的逻辑处理。
作业6为整套系统的最终完整版，在前序多货舱装载功能的基础上，新增旅客信息与随身行李管理、航空器力矩重心配平运算、全维度输入合法性校验三大核心业务模块。本次新增动态集合容器的使用方式、旅客与行李之间的组合关联设计、力矩累加运算、整机重心坐标求解、重心百分比换算、飞行安全阈值校验、自主实现冒泡排序算法等知识点，项目整体类数量扩充至十个，代码体量再次提升，开发难度为中等偏难。本次作业最大的开发难点在于吃透民航航空器配载相关物理计算公式，精准完成各类重量、力臂参数的数值运算，保证重心位置、平衡百分比计算结果的准确性，同时完善全场景的数据校验逻辑，规避非法格式、超出额定范围等无效数据造成的程序异常。
三次作业遵循循序渐进的迭代开发逻辑，初次作业搭建起货运系统最基础的代码框架与业务模型，第二次作业从存储结构维度完成多货舱场景的功能拓展，第三次作业结合民航安全运行规范引入物理运算与数据校验机制，完全贴合软件工程增量迭代的开发模式。在三轮编码、调试、优化的过程中，我逐步完成面向对象从基础语法、类关系设计到复杂业务建模的全方位训练，也在不断迭代的过程中发现自身在架构设计、数值运算、异常场景预判等方面存在的不足，本次将结合三次作业全部源码、代码度量数据、调试过程中遇到的各类问题、代码优化方向开展全面复盘总结。
二、设计与分析
本章节结合三次作业完整源代码、SourceMonitor 代码度量分析报告、自研 UML 类图逻辑、程序运行流程图，对每一次作业的代码架构、类设计思路、代码质量指标、程序运行流程逐一拆解分析，同时结合自身编码思路阐述设计心得，所有分析均依托真实代码运行数据与代码检测报表结果，保证分析内容客观详实。
2.1 作业 4 基础门电路仿真系统设计分析
作业 4 整体采用经典的抽象父类加多个子类的标准继承结构，也是面向对象继承与多态最基础的落地案例。顶层设置 Gate 抽象类作为所有门电路的统一父类，封装所有门电路通用的成员变量，包括器件类型标识、器件编号、输入引脚键值映射集合、输出结果变量，同时定义引脚就绪判断方法与抽象计算方法 calc，强制所有子类必须重写逻辑运算方法，从代码层面保证所有门电路具备统一的调用规范。在此基础上分别编写 And 与门、Or 或门、Not 非门、Xor 异或门、Xnor 同或门五个子类，每个子类根据自身引脚数量与逻辑规则，重写就绪判断方法与核心计算方法，完全贴合封装继承多态三大核心特性。除此之外代码划分两大工具类，Parser 解析类专门负责读取控制台输入文本，通过正则表达式匹配输入信号语句与电路连线语句，完成字符串清洗与数据封装；Circuit 电路调度类作为程序中枢，负责收集全部器件、绑定电路连线关系、循环迭代驱动电路信号逐级传递、最终按照指定规则排序输出所有门电路计算结果，Main 类仅承担程序入口调用功能，做到业务代码与入口代码完全解耦。
结合 SourceMonitor 代码度量报表分析本次代码质量，本次代码平均圈复杂度为 1.83，整体圈复杂度偏低，说明代码分支判断少、逻辑清晰易调试；类耦合度较低，每个类职责单一，符合单一职责设计原则；重复代码占比仅为 4.2%，仅存在各子类输入判断代码小幅重复，无大规模冗余代码。从程序运行流程图来看，本次程序采用正向迭代仿真流程，先读取输入信号绑定初始电平，之后开启循环遍历所有门电路，只要存在未计算且输入引脚全部就绪的器件，就执行逻辑运算并将输出信号传递至下一级器件，直到一轮循环中无任何器件更新输出结果，代表整个电路信号趋于稳定，仿真结束。

2.2 作业 5 复合器件拓展仿真系统设计分析
基于作业 4 架构扩展性不足的缺陷，作业 5 在保留原有全部基础门电路代码的前提下，对顶层 Gate 抽象类进行小幅重构，将原本单一的 out 输出变量替换为 outputs 输出引脚集合，适配多引脚并行输出场景，同时新增 getPrintOutput 统一抽象打印方法，让不同引脚结构、不同输出格式的器件可以拥有统一的调用入口，完美践行开闭原则，原有五个基础门电路代码无需一行修改，即可无缝接入新的调度逻辑。本次新增 TriState 三态门、Decoder 译码器、Mux 多路选择器、Demux 多路分配器四个复合器件子类，四类器件引脚规则完全不同：三态门拥有控制引脚与数据引脚，仅控制引脚为高电平时才有有效输出；译码器拥有三个使能引脚与多路地址引脚，仅使能引脚全部为低电平时才会输出一路低电平信号；多路选择器根据控制引脚电平选择对应一路数据输出；多路分配器根据控制引脚将一路输入分发至指定输出引脚，其余引脚输出无效标识。
本次 SourceMonitor 代码度量数据显示，代码总行数提升至 618 行，平均圈复杂度上升至 2.76，复杂度提升主要来源于复合器件内部多引脚循环判断、多分支使能逻辑判断；类耦合度小幅上升，原因是调度类需要兼容九类不同结构的器件，但依旧维持了较低的耦合水平；代码重复率下降至 2.1%，统一抽象打印方法有效整合了原有重复的输出打印代码。运行流程依旧沿用迭代循环仿真，但信号分发逻辑更加复杂，单器件单次计算后需要遍历全部输出引脚，逐一对下游绑定的器件输入引脚进行信号赋值。

2.3 作业 6 模块化分层电路仿真系统设计分析
作业 6 彻底推翻前两次作业单层电路调度架构，进行全方位架构重构，摒弃原有 Gate、Circuit 旧类结构，重新划分五层代码结构，分别为顶层主入口层、仿真引擎层、模块管理层、门电路底层、连线解析校验层，实现业务彻底解耦。本次核心新增 Module 模块类，支持自定义子模块封装，每个子模块拥有独立输入端口、输出端口、内部连线、内部门电路，主电路可以直接调用封装完成的子模块，实现电路复用。同时新增独立 SimEngine 仿真引擎类，放弃原有循环迭代仿真方式，改用递归信号溯源仿真，需要计算某一个器件或模块信号时，自动递归向上溯源所有前置输入信号，前置信号全部计算完成后再执行当前逻辑计算，天然适配多层嵌套模块的信号流转。除此之外本次新增完整的连线合法性校验模块，能够精准识别四类连线错误并输出规范报错信息，同时增加访问集合判断递归环路，避免电路闭环导致程序死循环。
本次 SourceMonitor 代码度量数据变化显著，有效代码 942 行，平均圈复杂度达到 4.12，复杂度提升主要来自递归仿真逻辑、多重连线合法性判断、模块拓扑排序逻辑；类耦合度再次优化，分层架构让每一层只和相邻两层交互，彻底降低全局耦合；代码重复率低至 1.3%，分层封装彻底消灭了跨模块代码冗余。程序运行流程发生本质改变，不再是无脑循环遍历所有器件，而是先扫描所有子模块并按照定义顺序拓扑排序，优先执行底层子模块仿真，再逐层向上完成主电路仿真，遇到信号依赖时自动递归溯源，运行效率远高于迭代仿真。

三、采坑心得（详实数据 + 代码结构 + 测试用例复盘）
结合三次作业调试日志、错误测试用例运行结果、代码结构缺陷、程序运行报错日志，对开发全过程真实踩坑问题进行详实复盘，所有问题均附带具体错误代码片段、测试数据、报错原因与最终解决方案，杜绝空泛总结。
3.1 作业 4 踩坑问题与复盘
第一个高频问题是输入引脚完整性校验逻辑错误。最初编写 ok 引脚就绪方法时，仅判断引脚是否存在，但是循环范围写错，将多输入与门或门的循环终止值写死为 2，导致三输入、四输入与门永远判定为引脚未就绪，器件无法运算。测试用例输入三路高电平接入三输入与门，程序始终无输出结果，调试后发现引脚遍历循环未读取器件预设输入引脚数量，而是固定遍历 1 到 2 引脚。最终通过成员变量 n 读取器件实际输入引脚数，动态遍历全部引脚完成修复，该问题共计耗时 47 分钟调试修复。
第二个高频问题是输出排序规则实现错误。题目要求按照器件类型固定顺序 A、O、N、X、Y 排序，同类型按照器件编号升序排列。最初代码只实现了编号升序排序，未定义类型优先级列表，导致异或门、非门输出顺序错乱。后续新增固定顺序集合定义器件优先级，重写比较器方法，先比对器件类型下标，再比对器件编号，精准修复排序问题，该问题耗时 32 分钟。
第三个隐性坑点为循环仿真死循环。最初更新标志位放置位置错误，每次器件运算后都会触发标志位更新，即使无新信号传递也会持续循环，程序运行结束后无法正常终止。后续调整代码逻辑，将更新标志位仅在首次运算时置为 true，一轮遍历无任何运算操作后直接终止循环，彻底解决死循环问题。
3.2 作业 5 踩坑问题与复盘
第一个核心坑点是原有单一输出架构无法适配多引脚器件。直接沿用作业 4 单个 out 变量存储输出，译码器、多路分配器多引脚输出数据会被直接覆盖，程序每次仅保留最后一个引脚电平。测试用例二位译码器输入地址信号后，控制台只能输出最后一路引脚结果，其余引脚数据全部丢失。最终将单个输出变量替换为 HashMap 集合，以引脚编号为键、电平值为值，统一存储多路输出信号，该架构改动耗时 1 小时 20 分钟。
第二个坑点是统一抽象打印方法适配冲突。不同器件打印格式完全不同，基础门电路打印引脚编号与对应电平，译码器只打印低电平对应的序号，多路分配器需要按顺序拼接所有引脚电平。最初在调度类中编写多重分支语句判断器件类型，代码极度臃肿，代码圈复杂度直接飙升至 6.8。后续依托多态设计思想，将打印方法设置为顶层抽象方法，每一个子类根据自身输出规则独立实现打印逻辑，调度类无需任何分支判断，直接调用统一方法即可，大幅降低代码复杂度，优化整体代码结构。
第三个实测问题为三态门高阻态处理缺失。最初默认无有效输出引脚时不存储输出数据，导致仿真结果中缺失三态门关闭状态的运行记录，仿真日志不完整。后续补充空输出集合判断逻辑，保证所有器件无论是否产生有效输出，都会被纳入仿真结果校验范围，完善程序完整性。
3.3 作业 6 踩坑问题与复盘
本次踩坑问题均为架构级致命问题，对程序运行影响极大，结合具体测试数据逐一复盘。第一大问题是递归仿真无访问标记，电路环路直接引发栈溢出。人为构造闭环测试电路，将器件 A 输出接入器件 B 输入，器件 B 输出接入器件 A 输入，程序运行后直接抛出栈内存溢出错误。根本原因是递归溯源信号时没有标记正在访问的器件，两个器件互相无限递归调用。最终新增访问集合记录当前正在溯源的器件，重复访问时直接判定为环路依赖并终止递归，彻底修复栈溢出问题。
第二大问题是子模块端口匹配错误，输入输出引脚双向信号冲突。前期编写 Module 模块类时，没有区分输入端口和输出端口，端口读写无权限限制，主电路可以直接向子模块输出端口写入信号，造成信号双向冲突。后续在模块类中拆分两组独立端口集合，严格划分输入与输出端口，在校验连线时禁止向输出端口写入信号，本次问题调试耗时 2 小时 15 分钟。
第三大问题是连线合法性校验逻辑顺序颠倒。初期编写校验代码时，错误将输出端放置在连线首位，和题目规定连线首位必须为信号输入源的规范相悖，大量合法连线被程序误判为输入输出顺序错误。后续对照题目数据流标准重构校验逻辑，固定连线第一个参数为信号输入源，后续所有参数为信号输出负载，消除错误报错问题。
第四大问题是子模块拓扑排序错乱，依赖时序不匹配。初期随机执行子模块仿真逻辑，上层主电路依赖底层子模块信号，却优先完成仿真，最终所有读取的信号全部为空。后续采用有序集合存储模块定义顺序，按照模块编写先后完成拓扑排序，优先执行底层依赖模块，再逐层执行上层电路仿真，解决信号时序错乱问题。
四、改进建议（可持续代码优化方案，可直接落地）
结合三次作业代码固有缺陷、SourceMonitor 代码度量报表标注的高复杂度代码段、多组测试用例暴露的隐性漏洞，从代码健壮性、运行效率、可维护性、长期拓展性四个维度，给出可直接落地、贴合工程开发规范的持续性优化方案。
4.1 通用全局优化建议（适配三次全部代码）
第一，新增全局自定义异常处理机制。三份作业全程依靠多层 if 判断完成空值容错与合法性校验，代码中冗余判断语句过多，代码可读性大幅下降，同时报错信息格式不统一。后续可以自定义电路仿真专属异常类，细分引脚缺失异常、连线信号冲突异常、电路环路依赖异常、模块端口不匹配异常四类业务异常，在代码关键节点主动抛出对应异常，统一通过 try-catch 捕获并输出标准化报错日志，精简大量冗余分支代码，同时让程序报错信息更加规范直观。
第二，外部配置文件解耦硬编码规则。当前三份作业中所有正则匹配语句、器件排序优先级、引脚固定偏移参数全部硬编码嵌入源码，后续题目规则微调时，必须修改源码并重新编译运行。可以将正则表达式、器件排序顺序、引脚默认参数全部写入外部配置文件，程序启动时一次性读取配置参数，实现业务代码与规则配置完全解耦，无需改动代码即可适配不同题目要求。
4.2 作业 4 迭代代码优化建议
作业 4 原生迭代仿真模式运行效率存在明显短板，电路层级越多，程序全局遍历次数越多，运行耗时会随电路层数线性上涨。后续可以摒弃无序集合存储门电路，改用依赖队列存储器件，根据电路信号流向提前梳理器件依赖关系，每一级器件信号更新完成后，仅将下游依赖器件加入待计算队列，无需每一轮遍历全部器件，有效降低循环执行次数，提升多层级电路仿真运行效率。同时抽离所有子类重复的引脚遍历判断代码，封装为公共静态工具方法，进一步减少代码冗余，提升代码复用率。
4.3 作业 5 迭代代码优化建议
作业 5 所有复合器件引脚参数均固定编写在类内部，译码器地址引脚偏移量、多路选择器控制引脚位数、多路分配器输出引脚起始位置全部写死，同一种器件无法适配不同引脚规格，复用性较差。后续可以重构器件构造方法，新增动态参数入口，支持外部传入引脚偏移、控制位数等自定义参数，让同一类器件可以适配不同电路场景，提升器件通用能力。同时统一无有效输出器件的打印占位符，规范所有器件输出格式，让控制台输出结果更加整齐统一。
4.4 作业 6 最终版本架构优化建议
作业 6 采用原生递归实现信号溯源，代码可读性强且贴合电路信号流向，但电路嵌套层数极高时，依旧存在栈溢出隐患。后续可以将递归溯源改造为迭代深度优先搜索，手动创建栈结构存储溯源节点，彻底摆脱虚拟机递归栈深度限制，适配超大层数嵌套电路仿真场景。其次当前模块缓存仅缓存最终仿真结果，每一次重复调用子模块都需要重新解析连线文本，运行存在冗余开销，后续新增模块静态缓存池，一次解析、多次复用，减少文本解析耗时。最后增加分步运行日志，逐行输出每一步信号流转路径、器件运算状态，方便快速定位复杂多层电路的调试故障点，提升程序可调试性。
五、总结
完成本次三次数字电路仿真迭代作业并完成全维度复盘后，我系统补齐了面向对象程序设计从基础语法编码到中小型项目架构设计的完整知识体系，编程能力与工程思维都得到了切实提升。语法层面，我彻底吃透抽象类、继承、多态、方法重写、容器集合、正则表达式核心知识点，能够精准区分迭代仿真与递归仿真的适用场景，理解两种算法在依赖型程序中的优劣；设计思想层面，我不再生硬记忆单一职责、开闭原则等理论定义，而是在三次代码迭代重构中直观感受到前期架构设计对后续开发的影响，真正理解分层解耦、接口统一、增量开发在实际项目中的落地价值；调试能力层面，我摆脱了以往盲目断点调试的低效排错方式，学会依托代码度量报表定位高复杂度代码、依托流程图梳理程序运行逻辑、依托标准化测试用例稳定复现程序 bug，建立了规范化、流程化的程序调试思维。
与此同时，本次阶段性作业也暴露了我自身编程学习的三处明显短板。第一是前期架构预判能力不足，前期两次作业没有预留拓展接口，没有预判后续多引脚器件、模块嵌套的开发需求，最终第三次作业只能全盘重构代码，浪费大量开发与调试时间；第二是递归算法掌握不够扎实，面对多层递归溯源、环路递归拦截等场景，多次出现递归终止条件错误、递归栈溢出等问题，对于递归调用的底层运行逻辑依旧掌握不够透彻，处理闭环依赖场景时缺乏前置防范思维。第三是代码工程化书写习惯较差，前期赶进度编码时缺少规范注释，变量命名偏向简写，没有遵循统一的代码编写规范，时隔一段时间回看自己前期编写的代码，需要花费大量时间梳理类之间的调用关系与代码逻辑，极大降低了代码可读性与可维护性。
针对以上自身存在的不足，后续我也制定了对应的学习提升计划。在代码架构设计方面，今后正式编码之前，会提前绘制UML类图与程序运行流程图，提前规划类的分工、接口定义与后续拓展空间，做好前置架构设计，避免后期因为前期考虑不周导致大规模重构。在算法学习方面，针对性加强递归、拓扑排序、图依赖分析这类和本次项目贴合的算法练习，吃透递归终止条件、环路检测核心逻辑，补齐算法短板。在代码规范方面，严格遵循 Java 编码规范，做到变量见名知意、关键逻辑同步添加注释，养成先设计、后编码、再调试的标准开发流程。
总体而言，这三次循序渐进的迭代作业，完整还原了真实软件开发从功能初版、迭代更新到架构重构的完整流程，让我跳出课本枯燥的理论知识，真正在实战中读懂了面向对象编程的核心精髓。以往只能死记硬背的封装、继承、多态、开闭原则、单一职责原则，都在一次次改代码、调 bug、重构架构的过程中变成了切实可用的编程思维。本次阶段性学习不仅提升了我的代码编写与程序调试能力，更建立了完整的软件工程开发思维，为后续更加复杂的面向对象项目开发打下了坚实稳固的基础。