1.前言
这三次pta训练集的情景主要是“数字电路模拟程序”，是一种处理离散信号的电子电路。与处理连续变化信号（如声音、温度）的模拟电路不同，数字电路只识别和运算两种基本状态：高电平（通常表示为“1”） 和 低电平（通常表示为“0”）。这正好与二进制数制系统相对应，使得数字电路成为所有计算机和数字系统的物理实现基础。
题目的知识点
三次pta题量
逐渐增加
第一次主要实现的是：基础逻辑门元件构成电路，各种电路门，通过输入连续变化信号，实现各个电路门输出的是低电平还是高电平。
第二次主要实现的是：在第一次的基础上，还包括多输入输出的组合电路元件（如数据选择器）以及元件引脚类型输入，输出之外，增加控制引脚（如三态门）。
第三次主要实现的是：在第二次的基础上，还增加子电路，以及增加程序异常输入的检测。
难度
逐渐增加。
第一次难度体现在用数字电路处理离散信号，高电平与低电平与二进制系统相对应以及输入的实现，电路信号之间的联系，信号的输出。
第二次难度体现在包含多个输入输出的组合电路元件，复杂度增加了。
第三次难度体现在增加了子电路，子电路的输入情况和主电路的输入情况不一样，子电路的信号输入是主电路的输出电路，以及对于程序异常输入的检测。
2.设计与分析
这是第一次PTA作业的类图设计，聚焦于组合逻辑电路的建模与仿真。图中包含了一个负责统筹调度的Main类，一个定义了电路元件通用行为（如计算逻辑、显示状态）的抽象基类Component，以及五个具体的逻辑门实现类（A、O、N、X、Y）。它们共同构成了 Composite 模式下的电路结构，通过多态机制实现了不同类型元件的统一管理与信号传播。
这是第二次PTA作业的类图设计，在第一次的基础上，增加了S，F，M等类。S是三态门（带控制端的开关，控制端为1时输出等于输入，否则高阻态），M是译码器（将输入编码转换为唯一输出0，其余输出1，需满足使能条件），Z是数据选择器（根据控制端编码从多路输入中选择一路输出），F是数据分配器（根据控制端编码将一路输入分配到多路输出之一）
第三次PTA的作业在第二次的基础上，增加了子电路，Link类是连接信息类（表示信号从源引脚到多个目标引脚的传递关系，包含原始字符串、源引脚、目标引脚数组）。所有具体元件继承自Component，通过多态实现各自的计算逻辑；Main通过Link列表驱动信号传播，最终按类型和编号排序输出有效元件的状态。
第一次PTA类图（基础数字电路模拟）分析
（1）整体规模与结构
该类图是数字电路模拟程序的初始版本，包含10个类：Main（主控类）、Link（连接类）、抽象基类Component，以及5种基础逻辑门（A-与门、O-或门、N-非门、X-异或门、Y-同或门）。
实体类（元件类）：A、O、N、X、Y为具体元件类，继承自Component。以A（与门）为例，代码约20行，含构造方法、calCount()（计算输出）、calLevel()（层级计算）、getReturn()（返回结果）、show()（展示状态）共5个方法；N（非门）因单输入，构造方法参数简化，方法数同为5。
主控类：Main作为系统入口，代码约40行，含main()（程序入口）、getOrder()（解析元件顺序）、addComponent()（注册元件）、setComponentInput()（设置输入）等方法，负责电路初始化与信号调度。
连接类：Link代码约15行，含raw（原始连接串）、source（源引脚）、targets（目标引脚数组）及构造方法，仅承载连接关系，方法数3 - 4个。
抽象基类：Component定义公共属性（type、num、output、listInputs）与抽象方法（calCount()、calLevel()、getReturn()、getName()、show()），代码约25行，方法数5个（含构造）。
（2）控制流与分支情况
实体类（元件类）：A的calCount()需遍历所有输入引脚（多输入与逻辑），包含“输入是否全1”的条件判断（分支覆盖率约23.9%）；N的calCount()仅单输入取反，无条件分支（分支覆盖率0）。
主控类：Main的setComponentInput()需处理输入格式解析（如A-1拆分为元件名与引脚号），包含字符串分割、映射操作等22次方法调用，分支覆盖率16.7%（因输入验证逻辑简单，条件判断少）。
连接类：Link无业务逻辑，仅存储数据，分支覆盖率0。
（3）复杂度与可维护性
实体类：A、O、X、Y的圈复杂度平均为4.76（因多输入/双输入的逻辑判断）；N因单输入，圈复杂度为1（无分支）。平均每个方法语句数：A的calCount()约10行（含循环遍历输入），N的calCount()约5行（单输入取反），整体方法简洁。
主控类：Main含32条语句（如输入解析、元件注册、信号传播），平均方法语句数32（主方法承载核心逻辑），最大圈复杂度8（因输入验证、元件查找的分支判断），嵌套深度3.31（无过度嵌套）。
抽象基类：Component的方法均为抽象或简单getter/setter，圈复杂度1，可维护性高。
第二次PTA类图（新增复杂元件）分析
（1）整体规模与结构
在第一次基础上，新增4类复杂元件（三态门S、译码器M、数据选择器Z、数据分配器F），类总数增至14。
新增元件类：S（三态门）含控制端、输入端、输出端，代码约25行，方法数5（calCount()需判断控制端电平）；M（译码器）需处理使能条件（如S1=1, S2+S3=0）与输入编码译码，代码约35行，方法数6（含使能判断、译码逻辑）；Z（数据选择器）需根据控制端选择输入，代码约30行，方法数5；F（数据分配器）需根据控制端分配输入到输出，代码约30行，方法数5。
抽象基类：Component因新增元件的属性（如S的控制端、M的使能引脚），代码扩展至30行，方法数仍为5（抽象方法）。
主控类：Main需解析新元件的输入格式（如S(2)1、M(3)1），代码增至50行，方法数新增createComponent()（根据类型创建元件），总方法数约8。
（2）控制流与分支情况
新增元件类：S的calCount()需判断“控制端是否为1”（分支覆盖率28.3%）；M的calCount()需先判断使能条件（如S11 && S2+S30），再根据输入编码选择输出引脚，包含多层条件分支（分支覆盖率25.5%）；Z和F的calCount()需解析控制端编码（如S1S0=00选D0），包含“编码→选择逻辑”的条件判断（分支覆盖率27%）。
主控类：Main的createComponent()需根据元件标识符（如S、M）实例化不同类，包含8次方法调用（如反射或工厂模式逻辑），分支覆盖率25.5%（因需处理9种类的情况）。
（3）复杂度与可维护性
新增元件类：M的圈复杂度最高（因使能判断+译码逻辑），最大圈复杂度24；S、Z、F的圈复杂度平均8.41（因单/双层条件判断）。平均每个方法语句数：M的calCount()约15行（含使能、译码、输出赋值），S的calCount()约12行（控制端判断+输出赋值）。
主控类：Main的平均方法语句数降至3.36（因逻辑拆分到createComponent()等方法），最大圈复杂度8（输入解析与元件创建的问题），嵌套深度2.46（条件判断层级减少）。
抽象基类：Component因属性扩展（如inputs映射支持多类型引脚），代码行数增加，但方法数未变，可维护性仍较高。
第三次PTA类图（新增管理与计算类）分析
（1）整体规模与结构
在第二次基础上，新增4个管理/计算类（Cargo、Flight、CargoSorter、LoadManifest），类总数增至18，系统从“单一电路模拟”扩展为“电路+货物管理”的复合系统。
实体类（货物/航班）：Cargo（货物）含name、weight，代码24行，方法5（getter/setter）；Flight（航班）含flightNo、maxWeight，代码24行，方法5。
管理类：CargoSorter（货物调度）含addCargo()、sortCargos()，代码25行，方法1（核心排序逻辑）；LoadManifest（舱单管理）含addCargo()、getFlight()，代码44行，方法9（含数据维护、查询）。
计算类：WeightBalanceCalculator（重心计算）含纯计算方法（如calcTotalWeight()、calcMoment()），代码约30行，方法3（无状态，仅工具方法）。
主控类：Main需协调电路与货物管理模块，代码增至60行，方法数新增initCargoSystem()（初始化货物模块）、runCargoSimulation()（运行货物调度），总方法数约10。
（2）控制流与分支情况
实体类：Cargo、Flight为纯数据类，无业务逻辑，分支覆盖率0。
管理类：CargoSorter的sortCargos()含冒泡排序的嵌套循环（分支覆盖率30.8%，因需比较重量并交换）；LoadManifest的addCargo()需判断“货舱是否超重”，包含单层条件分支（分支覆盖率28.3%）。
计算类：WeightBalanceCalculator的方法为纯数学计算（如totalWeight = sum(cargo.weight)），无条件分支，分支覆盖率0。
主控类：Main的runCargoSimulation()需调度电路与货物模块，包含15次方法调用（如cargoSorter.sortCargos()、flight.setTotalWeight()），分支覆盖率16.7%（因模块间逻辑简单）。
（3）复杂度与可维护性
实体类：Cargo、Flight的圈复杂度1，方法简洁（getter/setter）。
管理类：CargoSorter的最大圈复杂度5（冒泡排序的嵌套循环），平均方法语句数4.00（排序逻辑+数据维护）；LoadManifest的平均方法语句数6.28（含9个方法，如数据查询、更新）。
计算类：WeightBalanceCalculator的圈复杂度1（纯计算方法），可维护性极高。
主控类：Main的平均方法语句数3.36（逻辑拆分到多个子方法），最大圈复杂度7（模块调度与错误处理），嵌套深度2.19（无过度嵌套）。
3.踩坑心得
三次数字电路模拟程序的迭代开发过程中，遇到的问题多集中在需求理解偏差、逻辑设计疏漏与边界场景考虑不足，大部分问题不属于语法错误，排查定位的成本较高，具体踩坑点如下：
第一类问题是输入解析与元件创建的逻辑遗漏。初始实现连线解析时，默认仅连线的目标端需要对应元件实例，仅对目标引脚做元件创建，未处理源端的门元件。该问题在单级电路中不会暴露，但遇到两级及以上的级联电路时，前级门没有实例化，信号链路从源头断裂，导致输出结果完全错误。排查过程中先后调整过迭代次数、子电路仿真逻辑，均未解决问题，最终通过构造最简两级级联用例、逐节点打印中间信号值，才定位到源端元件缺失的根因。除此之外，输入字符串分割也存在疏漏，最初使用单空格作为分隔符，遇到多空格、制表符分隔的测试用例时，会解析出空字符串，导致元件名、引脚号识别失败，后续替换为正则匹配多空白符才解决该问题。带括号的元件名解析也出现过偏差，曾误将括号内的引脚数识别为元件编号，导致元件排序、查找逻辑全部失效。
第二类问题是信号仿真的迭代逻辑与收敛问题。最初的主电路仿真流程，是先为主电路所有门赋值输入，再执行子电路仿真，该顺序会导致子电路更新后的输出无法同步到本轮主电路计算，信号传递多出一轮延迟，深层级联电路会出现收敛不足、结果偏差的问题。同时初始实现未在每轮迭代开始时清空元件的输入缓存，上一轮的信号值会持续残留，输入引脚的数值不断累积，计算结果持续失真，该问题通过逐轮核对输入映射内容才定位到。迭代次数的设置也经过了多次调整，初始设置 20 次迭代仅能支撑浅层电路，随着电路深度增加，需要和电路深度匹配的迭代次数才能保证完全收敛，最终将全局迭代上限调整到 200 次，才覆盖了所有测试用例的深度需求。
第三类问题是子电路的概念理解与实现偏差。核心误区是混淆了子电路端口在连线中的角色：初始默认子电路的 INPUT 端口是连线的信号源，OUT 端口是连线的信号目标，实际逻辑完全相反 —— 站在连线视角，子电路 INPUT 端口是接收信号的目标端，OUT 端口是提供信号的源端。该理解偏差导致子电路所有连线的源目判断错误，连带异常检测逻辑全部失效，单子电路、多子电路的多个测试点均出现结果错误，最终对照题目样例逐字段核对，才纠正了该概念偏差。另外子电路的输出顺序也存在问题，最初直接遍历 HashMap 的键集输出，忽略了 HashMap 的无序特性，多子电路场景下输出顺序随机，和题目要求的编号升序不符，调整为先提取编号排序、再按序输出后才解决。
第四类问题是异常检测的规则理解与实现疏漏。同样存在概念理解偏差：最初将元件的输入引脚等同于连线的输入，元件的输出引脚等同于连线的输出，导致 “单元件输入引脚” 这类无输入场景，误报为无输出，和题目样例完全不符。重新梳理规则后明确：连线中提供信号的为输入（全局输入、元件输出脚、子电路输出口），接收信号的为输出（元件输入脚、子电路输入口），才修正了异常判断逻辑。除此之外，异常优先级也出现过顺序错误，同一条连线触发多种异常时，未按题目给定的优先级顺序输出，调整判断分支的先后顺序后才符合要求。引脚冲突的检测也存在疏漏，最初仅在单条连线内校验，无法检测跨连线的引脚冲突，新增全局引脚驱动映射后，才实现了跨连线的冲突校验。
第五类问题是大规模电路的性能超时。初始实现未做性能优化，每轮迭代都对所有连线执行字符串截取、拆分操作，元件查找也通过遍历 ArrayList 线性匹配，小规模电路运行正常，但门数量较多的大测试点会超出时间限制。后续做了两项优化：一是将连线预解析为对象，提前拆分好源端和目标端，迭代时直接使用，避免重复的字符串操作；二是新增 HashMap 存储元件名到实例的映射，将元件查找的时间复杂度从 O (n) 降至 O (1)，优化后运行效率提升数倍，通过了所有大用量测试点的时限要求。
4.改进建议
5.总结
三次数字电路模拟程序的迭代，是从基础功能到复杂系统的逐步落地过程：从第一版实现五种基础门电路的平面仿真，到第二版支持子电路模块化封装，再到第三版补充完整的异常检测体系，功能逐步完善的同时，也覆盖了面向对象设计、算法选型、边界处理等多个维度的实践。总的来说，这三次迭代不是简单完成作业，而是完整经历了一个小型软件从需求到实现、从调试到优化的全流程。它让我明白，写代码不是目的，解决问题、构建可维护的系统才是核心。后续我会按照改进建议逐步重构代码，优化架构和算法，把这个数字电路模拟器做得更完善，也为后续时序电路、更复杂元件的扩展打好基础。
收获
知识层面，首先深化了 Java 面向对象的落地应用。抽象类、继承、多态不再是书本上的概念，而是实际解决了多类型元件的统一管理问题：通过 Component 抽象类统一定义元件的属性与行为，五个门电路分别实现自身的运算逻辑，主电路通过统一接口调用，降低了代码的冗余度，也让结构更清晰。其次是熟练掌握了 Java 集合框架的场景化应用：HashMap 用于元件名到实例的映射，解决了大规模电路的查找性能问题；ArrayList 用于管理线性的元件、连线集合；自定义 Comparator 实现了 “按类型排序、同类型按编号升序” 的输出规则，不同的集合工具匹配对应的业务场景，提升了代码的运行效率与可读性。除此之外，字符串处理、正则匹配、迭代求解的思想也在实践中得到了巩固。
能力层面，最核心的收获是问题定位与调试能力的提升。本次作业中的错误大多为逻辑错误，无编译报错，需要通过现象反向推导根因。实践中逐步形成了排查流程：先用最简用例复现问题，缩小问题范围；再通过打印中间变量沿信号链路核对，定位出错节点；最后通过排除法锁定问题代码。整个过程锻炼了逻辑推导能力，也积累了系统排查问题的经验。同时也明确了需求理解的重要性：多数 bug 的根源是对题目规则的理解偏差，而非代码实现能力不足，后续开发中会先完整梳理所有约束规则，确认理解无误后再动手编码，避免方向性错误。
不足
同时也暴露了自身的明显不足。一是前期架构设计能力薄弱，第一版开发时未考虑后续子电路、异常的扩展需求，导致每次迭代都需要大量修改原有代码，重构成本高。如果初期就做好分层与抽象设计，后续迭代会更顺畅。二是边界场景考虑不全面，默认输入均为合法格式，对异常场景、边界输入的覆盖不足，很多问题都是提交后才暴露。三是工程化意识不足，代码职责划分不清晰，缺少注释与测试用例，代码的可维护性较差。
改进建议
对于课程，希望老师在课堂上能多结合真实项目案例进行讲解，让我们更直观理解面向对象的实际用途；同时可以对作业中常见错误、典型坑点进行集中讲解，帮助我们少走弯路。