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

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

前言

本次作业总结围绕“数字电路模拟程序”展开，从第一次作业的基础逻辑门模拟，到第二次作业的多输入门与信号传播，再到第三次作业的子电路支持与异常处理，三次迭代让我亲历了一个完整软件系统的演进过程。这篇博客将真实记录我的解题思路、遇到的问题以及调试过程。

作业集整体回顾

阶段	核心功能	新增类数量	主要难点
第一次作业	五种基础逻辑门模拟、单信号传播	6个	面向对象设计、逻辑门计算模型
第二次作业	多输入门支持、信号主动传播	8个	引脚映射、迭代计算收敛
第三次作业	子电路定义与引用、五级异常检测	10个	递归实例化、异常优先级管理

一、第一次作业：打好基础

1.1 题目理解

第一次作业的要求是：设计一个数字电路模拟程序，能够模拟与门、或门、非门、异或门、同或门五种基础逻辑门。输入包括元件定义、信号输入和连接信息，程序需要计算并输出所有元件的输出引脚电平。

拿到题目后，我首先分析了需要处理的数据：元件类型和编号、输入信号值、引脚连接关系。输出要求是按A、O、N、X、Y的顺序输出所有有效元件的输出电平。

1.2 我的设计思路

我决定将系统划分为六个类：

1. Gate抽象类：定义所有逻辑门的通用属性和方法
2. AndGate类：实现与门逻辑
3. OrGate类：实现或门逻辑
4. NotGate类：实现非门逻辑
5. XorGate类：实现异或门逻辑
6. XnorGate类：实现同或门逻辑

这样划分的原因是：每个门类只实现自己的逻辑，符合单一职责原则。Gate基类负责管理输入信号和输出值，子类只需重写compute()方法。

1.3 遇到的问题及解决过程

问题一：输入解析的复杂性

连接信息的格式是[输出引脚 输入引脚1 输入引脚2 ...]，需要正确拆分。我使用按空格分割的方法，然后第一个元素作为输出，其余作为输入。在解析过程中，需要特别处理元件名中包含括号的情况，如A(8)1，确保正确提取元件名和引脚号。

问题二：信号传播的时机

我最初的想法是在读取完所有连接后，一次性计算所有门。但这样做有个问题：如果一个门的输入依赖于另一个门的输出，必须按照依赖顺序计算。

后来我改成迭代计算：反复遍历所有门进行计算，直到没有门的输出发生变化为止。这样即使依赖关系复杂，也能正确传播信号。

问题三：输出格式的排序

题目要求按照与门、或门、非门、异或门、同或门的顺序输出，同类按编号从小到大排序。我使用自定义比较器实现排序，定义了AONXY的排序基准，确保门类型按正确顺序输出。

1.4 输出格式的处理

每个元件的输出格式为元件名-0:电平值，其中0是输出引脚号。如果元件没有有效输入，则忽略该元件，不输出。在输出时，需要过滤掉没有有效输入的元件，只输出那些能够计算出结果的元件。

第一次作业的类图：

第一次作业的复杂度分析：

二、第二次作业：多输入门与信号传播

2.1 题目理解

第二次作业的复杂度明显增加。与门和或门不再限于两个输入，而是支持多个输入引脚（如A(8)1表示8输入与门）。同时，信号传播机制需要强化，一个输出引脚可以连接多个输入引脚。

核心要求是正确处理多输入门的引脚映射，以及信号的可靠传播。

2.2 我的设计思路

第二次作业新增了两个关键机制：

1. 引脚映射：在Gate基类中增加映射表，记录每个引脚对应的信号源。
2. 主动传播：门计算完成后，主动将结果推送给所有依赖它的门。

我新增了引脚解析方法，用于将外部信号映射到具体引脚。对于多输入门，每个引脚都需要独立映射。

2.3 遇到的难点及解决过程

难点一：引脚编号的解析

元件引脚格式为A(8)1-2，表示与门A(8)1的2号引脚。我需要正确解析出元件名和引脚号，然后建立映射。我使用字符串拆分方法，以-为分隔符，提取引脚号。

难点二：信号传播的稳定性

在迭代计算中，可能出现循环依赖（虽然题目保证不会出现）。我设置了最大迭代次数100次，防止死循环。每次迭代遍历所有Gate，如果某个Gate的计算结果发生变化，就标记为已改变并继续下一轮迭代。

难点三：未连接引脚的悬空处理

如果某个输入引脚没有连接任何信号，该门无法计算，应该忽略。我在compute()方法中检查是否所有引脚都有值，如果有缺失则返回false，表示未完成计算。

2.4 输出格式的细节

第二次作业的输出格式保持不变，但元件名可能包含括号（如A(8)1），需要确保解析正确。在输出时，同样需要过滤掉没有有效输入的元件。

第二次作业的类图：

第二次作业的复杂度分析：

三、第三次作业：子电路与异常处理

3.1 题目理解

第三次作业的复杂度最高，新增了两个核心功能：

1. 子电路支持：允许用户定义子电路（格式为C1: ... endc），并在主电路中引用（如C1-A）。子电路内部的元件编号与主电路独立。
2. 异常检测：需要检测并报告5种类型的输入异常，并按优先级输出最高优先级的错误信息。

3.2 我的设计思路

第三次作业新增了四个关键组件：

1. SubCircuitDef类：存储子电路的定义（输入、输出、内部连接）
2. 子电路实例化方法：实例化子电路，创建内部Gate实例
3. OutputProxyGate类：作为子电路输出的代理，连接内部和外部的信号
4. 异常处理模块：按优先级检查5种异常

子电路的实例化是核心难点：每个子电路被引用时，需要创建独立的Gate实例，信号完全隔离。

3.3 遇到的难点及解决过程

难点一：非门信号丢失

在子电路中使用非门时，输出值经常无法正确传递到外部。例如，子电路定义了一个非门，其输出连接到子电路的输出引脚，但主电路引用该子电路时无法获取到正确的输出值。

问题根源：非门计算完成后，输出值没有正确传播到输出代理。修复方法是在非门的计算逻辑中，显式地将输出值传递给输出代理。

难点二：异常优先级判断错误

对于某些异常输入，我错误地输出了较低优先级的错误信息。例如，[A(2)1-1 A(2)1-0] 应该输出顺序错误，但错误地输出了包含多个输入。

原因：优先级1的条件判断过于宽泛。修复方法是精确区分“多个输入”和“顺序错误”的场景。先检查是否有多个输入引脚，再检查顺序是否正确。

难点三：单引脚情况的判断

关键规则是区分输出引脚和输入引脚：

• 对于[A(2)1-0]（输出引脚），应该输出没有输入的错误
• 对于[A(2)1-1]（输入引脚），应该输出没有输出的错误

我在异常处理中增加了引脚类型判断，根据引脚号区分输出引脚（0）和输入引脚（大于0）。

难点四：子电路实例化冲突

同一个子电路被多次引用时，内部元件名称需要添加前缀。例如C1和C2都包含N1，应该分别命名为C1-N1和C2-N2，避免命名冲突导致信号混乱。

3.4 输出格式的精确匹配

第三次作业的输出格式非常严格。特别是异常信息，必须完全匹配：

ERROR: [A(2)1-0] include none output

ERROR: A(2)1-1 input signal conflict

我反复对照输出样例，逐字检查空格和标点，确保异常信息的精确匹配。

第三次作业的类图：

第三次作业的复杂度分析：

四、采坑心得汇总

4.1 输入格式问题

使用Scanner时，nextInt()、nextDouble()等方法会留下回车符，影响后面的nextLine()。解决方法是在这类方法后面加一行scanner.nextLine()来消耗回车符。在解析连接信息时，要特别注意空格的处理，使用按空格分割的方法可以正确处理多个连续空格。

4.2 信号传播的稳定性

迭代计算虽然实现简单，但需要注意收敛性。设置最大迭代次数100次，防止死循环。同时要正确处理悬空引脚，如果某个门的所有输入都没有值，应该忽略该门。

4.3 组合与聚合的区别

第三次作业中的子电路实例化体现了组合关系：子电路内部的Gate生命周期与子电路绑定，子电路销毁时内部Gate也应该销毁。而在主电路中，Gate是独立存在的，体现了聚合关系。

4.4 异常优先级的精确控制

5种异常必须按优先级检查：

1. 包含多个输入（优先级最高）
2. 没有输入
3. 没有输出
4. 顺序错误
5. 输入冲突（优先级最低）

任何顺序错误都会导致输出与预期不符。因此，必须严格按照优先级顺序进行检查，一旦发现较高级别的异常，立即停止检查并输出对应的错误信息。

4.5 非门信号的特殊性

非门是唯一一个单输入门，在信号传播中容易被忽略。需要特别注意：

1. 非门的输入源可能来自直接添加的信号源而不是通过引脚映射
2. 在解析引脚输入时，对于没有指定引脚的信号源，默认连接到引脚1

4.6 子电路实例命名的独立性

子电路内部的元件编号与主电路独立，不同子电路的编号可以相同。因此，实例化时必须使用子电路名作为前缀，避免命名冲突。例如，C1-N1和C2-N1分别表示子电路C1和C2中的非门。

4.7 输出格式的严格匹配

判题系统采用字符串严格比对，输出中的空格、标点符号、换行都必须与样例完全一致。调试时可以用文本对比工具逐字检查，确保每一个字符都正确。

五、改进建议

5.1 优化迭代计算效率

当前采用迭代计算，对于大规模电路效率较低。改进方案是引入拓扑排序，按依赖关系顺序计算，避免不必要的重复迭代。

5.2 增强异常处理的模块化

将异常检测逻辑抽取为独立的异常处理类，与解析逻辑解耦，便于测试和维护。这样可以使代码结构更清晰，也方便增加新的异常类型。

5.3 引入工厂模式创建Gate

使用工厂模式封装Gate的创建逻辑，便于扩展新的门类型。当需要增加新的门类型时，只需要在工厂中添加对应的创建逻辑，而不需要修改现有的代码。

5.4 做好类的单一职责，降低耦合度

在我的代码中，Main类承担了多个职责：输入解析、子电路实例化、异常检查、信号模拟、输出控制。当题目需求发生变化时，我几乎需要重写整个Main类，这就是耦合度过高带来的问题。

改进方案：应该将输入解析交给解析类，子电路实例化交给实例化类，异常检查交给异常处理类，信号模拟交给模拟器类，输出交给格式化输出类，Main只负责协调这些组件的工作流程。

六、总结

6.1 主要收获

通过三次迭代作业，我掌握了以下内容：

1. 面向对象设计：抽象基类、继承、多态的实际应用
2. 信号传播机制：主动传播vs被动轮询，迭代计算的收敛性
3. 异常处理设计：优先级管理、错误信息规范化
4. 递归解析：子电路定义的递归实例化
5. 迭代开发：从简单功能逐步扩展，保持代码的可扩展性

6.2 需要加强的地方

通过三次作业的迭代，我深刻体会到了好的代码设计需要遵循单一职责原则，每个类只做一件事，每个方法只做一件事。代码不仅仅是写给机器执行的，也是写给（包括未来的自己）人阅读的，因此清晰的注释同样重要。

在今后的学习和开发中，我会更加注重代码的可读性和可维护性：

1. 在设计时就考虑职责划分，避免一个类承担过多责任
2. 在编码时保持方法短小精悍（不超过50行）
3. 在完成后补充必要的注释，特别是复杂逻辑的解释
4. 定期进行代码重构，消除重复代码和过大的类

6.3 对课程的建议

1. 可以增加设计评审环节，在编码前分享设计思路
2. 可以提供更多边界测试用例供自测参考
3. 可以加强输入格式处理的说明
4. 可以在作业中增加对代码复杂度的要求，引导写出更高质量代码

三次作业做下来，每次调试找到问题的过程，都是最有价值的收获。希望下次作业能做得更好。

三次作业代码规模与复杂度对比：

指标	第一次作业	第二次作业	第三次作业
代码行数	~200行	~350行	~600行
类数量	6个	8个	10个
方法平均复杂度	3.2	4.5	6.8
最高方法v(G)	5	8	15
测试用例通过率	100%	100%	100%