一、前言
本阶段的OOP-PTA大作业围绕数字电路模拟程序展开，前后经历了三次迭代开发。从最开始五个基础逻辑门，到增加新的元件，再到最后的子电路和异常检测，每一次迭代都在前一版的基础上增加了新的系统逻辑与系统约束。接下来是我结合实际的代码实现，对此次大作业进行的系统分析和总结。
知识点：
第一次迭代主要实现五种基本逻辑门（与门、或门、非门、异或门、同或门）的建模与仿真，覆盖位运算逻辑、输入输出映射、类封装与方法设计等知识点
第二次迭代新增三态门、译码器、数据选择器、数据分配器四种复合元件，这些元件的共同特征是引脚类型多元化——除了输入输出引脚外，还引入了控制引脚。覆盖引脚角色分类、多引脚协同控制、组合与聚合关系等知识点
第三次迭代增加了子电路机制与异常输入检测。子电路要求系统支持电路嵌套与递归求值，涉及组合模式的应用；异常检测要求程序在解析阶段识别并报告五种特定格式错误，覆盖输入校验设计、错误处理机制、多模块化代码设计等知识点
题量：
三次迭代的代码量逐轮递增
第一次迭代只需要五个元件类和少量辅助类，完成基本的门电路建模和单层电路仿真；
第二次迭代增加到十个左右的类，同时添加了控制引脚、输出引脚的角色区分，以及查找、排序等工具类；
第三次迭代的类达到十五个左右，继续添加了子电路对象和异常校验类，同时子电路的递归求值作为新的业务加入，代码行数相比第二轮翻了一倍
难度：
难度曲线同样是阶梯式上升。第一次迭代只需多次循环判断运行电路就能解决，类设计也较为简单；
第二次迭代的难点在于加入了许多新的电路元件，需要用一个统一的数据结构描述引脚数量、类型各异的九种元件，达成高复用性，而不是为每种元件单独设计类结构；
第三次迭代难度最大，既要实现子电路的递归求值与信号传播，又要处理五种异常情况的检测与优先级排序，还要考虑子电路与主电路的命名空间隔离问题，导致第三次迭代我仍有部分测试点未能通过
二、设计与分析
以下是第一~三次迭代的代码分析
第一次：
Factory（工厂）类内部的switch语句和复杂的初始化逻辑和Handle（处理）类的方法较多导致它们的平均语句高于平均值，需要减少嵌套逻辑同时把大方法拆除提取成小方法来降低，否则代码臃肿；其他的逻辑门类的平均语句少且圈复杂度低，容易维护，设计可行
第二次：
Output（输出）类的圈复杂度24.0意味着方法内部包含了过于多的条件判断和循环逻辑。同时，平均语句高达44。0，说明这个方法体极其冗长，可以通过再细分方法或创建新类分摊代码来进行减少；
Factory（工厂）类的圈复杂度减少到15.0，可以通过引入策略模式，定义Creator接口来为每种具体的组件创建独立的实现类，减少圈复杂度；
第三次：
我参考组合模式，设计了Circuit_part抽象类，Component继承它作为叶子节点，Sub_circuit继承它作为组合节点。子电路内部维护自己的Circuit对象，运行时先接收外部信号，在自己内部传播一遍，然后把输出值返回；异常检测方面，我写了Validator类专门处理五种异常情况的检查；
Validator类的逻辑比较冗杂，分支率较高，可以再次拆分为多个单独的校验类。Sub_circuit类内部维护了多套映射关系，有简化的空间，但整体上实体层、业务逻辑层、输入输出层、应用层的分层已经比较清晰。
以下是第一~三次迭代的UML类图
第一次：
核心设计采用面向对象的多态架构，Component作为抽象基类，各门电路（AndGate、OrGate 等）继承并实现各自的 compute方法，便于扩展新逻辑门；Circuit负责管理组件容器，Factory负责对象创建，Handle负责解析输入并构建电路，三者分工明确
第二次：（为方便观看，省略工具类和输入输出类和基础逻辑门类的类图）
在基础 Pin之上衍生出了专用的 ControlPin和 InputPin，分别用于处理控制信号与常规数据信号，对复杂信号类型进行精细区分；核心业务引入了 Multiplexer（多路复用器）、Decoder（译码器）和 Demultiplexer（解复用器），表明该模拟器具备处理复杂数据选择与分发的能力；Tri_stateGate（三态门）的加入支持“总线共享”逻辑，而 Connect类则负责统筹这些高级组件间的物理连接，构成了完整的电路拓扑管理
第三次：（为方便观看，省略工具类和输入输出类和基础逻辑门类的类图）
Sub_circuit继承自 Circuit_part，内部嵌套了另一个 Circuit实例，配合 collect_leaf方法，实现了电路元件向底层基本组件的递归遍历Connect类不仅负责顶层连接，更提供了 bind_sub_src和 bind_sub_in专门处理子电路内部引脚与外部电路绑定的方法，解决了多层电路嵌套时的端口同步映射问题；InputPin和 OutputPin均增加了 src（源）和 circuit（所属电路）属性，使得它们能够精准识别自身在复杂层级结构中的位置并验证信号源的有效性
三、踩坑心得
首先，是我对引脚编号规则理解不到位，第二次迭代做译码器的时候卡了很久，题目规定的控制引脚和输入输出引脚再不同的元件上编号是不一样的。我一开始想当然地认为输入引脚一直都是从1开始编号，结果控制脚才是占1的，所以逻辑不对，后来重新阅读题目中的引脚编号规则，我又花时间重构了一次代码，在Connect类中根据controlCnt和inputCnt来判断引脚属于哪一类，才算解决；
其次，对于子电路求值顺序，我起初是同暴力循环遍历草草了事，在第三次迭代中，子电路内部的元件之间有依赖关系，如果不管顺序，可能会读到还没赋值的引脚，导致报空指针或者是电路信号无法传递到全部元件；
接着，异常优先级处理也需要细心思考，第三次迭代要求如果一条连接有好几种异常，按特定顺序只输出第一个，如果多条连接里有多个异常时的话，输出的顺序就不对了，改成在Validator里先检查所有异常类型，按优先级顺序返回第一个发现的就能解决了；
输出排序的优先级也很容易踩坑，标准的输出要求先按子电路编号排序，再按门类型顺序（A、O、N、X、Y），再按门编号大小排序。主电路的门排在最后，但是题目没有明确指出，需要多次尝试；
尽管完成了大部分功能，第三次迭代我仍有部分测试点未能通过，主要的错误应该来自：子电路多层嵌套时的信号传递丢失，当子电路内部再嵌套子电路时，我的代码在处理信号传递时出现了断层，内部的子电路无法正确获取到外层子电路的输出信号，根源在我前几次迭代的整体架构和代码设计没做好，以后要提前搭建好完备精密的代码逻辑，才能让之后写的代码更顺利与正确
四、改进建议
首先要减少静态方法的使用，目前许多类全是静态方法，可以通过充血模型将这些静态方法融合进对象类之中，能够封装更完全；
然后可以将子电路接口标准化，现在Sub_circuit维护了inputKeys、inputVals、outKeys、outVals四套映射，又在Circuit里搞了outNodes，两套机制并存，容易混乱，子电路在外部可以像一个普通元件一样，有输入引脚列表和输出引脚列表。外部连接时直接把信号接到这些引脚上，子电路内部自己处理映射关系；
接着，可以学习拓扑排序算法，替代掉暴力询问，现在计算轮次靠暴力循环遍历，可以用拓扑排序确定计算顺序，或者用队列做广度优先传播，信号从一个元件传到下一个，直到没有新信号产生为止，减少代码的空间和时间复杂度，且使得电路信号传递模拟更加真实
最后，还可以继续优化工厂模式，再通过策略模式，创建接口抽象创建行为，提高扩展性，更遵循开闭原则
五、总结
这次大作业的难度比上次大作业的难度整体提升了一个档次，更何况还要面对完全没有接触过的数字电路，对于其中的运行逻辑我最初是一窍不通的，在对题目思考和网络学习中我才得以了解到一些关联的知识，减轻做题的错误率，不过做题还是在边试错边纠错的过程中完成的；
完成这次大作业后，我对代码扩展性的重要性有了更深刻更丰富的理解，如果一段代码的扩展性低，在增加或修改业务功能时会十分麻烦，需要花费大量时间重新阅读和修改代码，本人已经首当其冲；
技术上最大的收获是对“抽象类和接口”这件事有了切身体会，抽象类和接口就像是两个相似的通用模型，各有各的大用途，结合会产生多种设计模式来应对不同业务需求，就比如第三次迭代使用的组合模式应对电路和子电路的关系；
第三轮未通过的测试点也让我清醒地认识到，理解设计模式和正确应用设计模式之间还有很大的距离。我虽然知道组合模式的概念，但在实现子电路的多层嵌套时，没有考虑到信号传递的递归性和实例状态的独立性，导致代码在复杂场景下失效。这说明我对设计模式的理解还需要在后续的学习中通过更多的实践来加深；
总的来说，这次作业让我具有更加严谨的做题思维和代码设计思维，虽然第三次迭代未能完全通过所有测试点，但也正是那些没通过的测试点，让我看到了自己设计能力的短板，也明确了下一步努力的方向，我会继续努力的💪！