前言：
数字电路模拟程序设计是一个综合性较强的题目，融合了字符串处理、图算法、逻辑运算等多个知识点
-
第一次题目：核心知识点在于数字电路基础，五种基本逻辑门的真值表和逻辑功能；拓扑排序/图遍历，电路连接形成有向图，需要按信号流向顺序计算；字符串解析，复杂的输入格式解析；多输入门处理，与门和或门支持2个以上输入引脚；信号传播模拟，电平从输入引脚通过元件传播到输出引脚。
对初学者而言题量和难度应该都是中等偏上。 -
第二次题目：新增核心知识点 控制引脚概念；高阻态处理，三态门的特殊状态需要特殊标记和处理；多输出元件；编码译码原理；选择器/分配器功能。
此外还有基础知识点扩展：复杂引脚排序规则；无效状态处理；特殊输出格式，译码器只输出有效引脚编号，数据分配器输出带"-"的字符串。
题量较第一次多出很多，难度也偏难，迭代设计时代码改动偏大。
一. 数字电路模拟程序-1
-
题目
编程实现数字电路模拟程序，电路中包含与门、或门、非门、异或门、同或门五种元件，用A、O、N、X、Y 分别用作与门、或门、非门、异或门、同或门五种元件的元件标识符。
电路中的每个与门、或门用“标识符(输入引脚数)+编号”作为其元件名。
引脚信息由“元件名-引脚号”构成。- 电路的输入格式：INPUT:英文空格+输入1+”-”+输入信号1+英文空格+输入2+....+输入n+”-”+输入信号n
- 引脚的连接信息格式：[+输出引脚+英文空格+输入引脚1+。。。。+英文空格+输入引脚+]
- 约束条件：一个输出引脚可以连接多个输入引脚，即将输出引脚的信号传给每一个输入引脚。但一个输入引脚不能连接多个输出引脚。输出引脚不能短接在一起。
- 输入结束信息：所有输入以end为结束标志，end之后出现的内容忽略不计。
- 程序输出：按照与门、或门、非门、异或门、同或门的顺序依次输出所有元件的输出引脚电平。同类元件按编号从小到大的顺序排序。
-
设计与分析：
- 类图设计：如下图
![屏幕截图 2025-11-30 165156]()
- 代码分析：
![image]()
![image]()
- 基础代码规模：
代码总行数420行，有效代码240行
包含8个类/接口，平均每个类有4.13个方法，每个方法平均5.39行代码 - 复杂度与嵌套深度：
最复杂方法：Main.main()，复杂度6，位于第 4 行
最大嵌套深度：7，嵌套深度7属于较高风险
平均复杂度1.81、平均嵌套深度1.77：
整体复杂度偏低，但局部方法（如Main.main()）和局部代码块（嵌套深度 7）是优化重点。 - 其他指标：
注释占比7.1%：
注释比例过低，代码的可读性和维护性会受影响，建议补充关键逻辑的注释。
分支语句占比22.1%：
分支语句（if/switch 等）占比适中，逻辑分支不算密集。
- 类图设计：如下图
-
问题与改进：
- Circuit核心类臃肿
当前问题：Circuit类承担了组件管理创建、输入处理、连接处理、输出计算、排序等多个职责，后续迭代改动大复杂度高。
改进方案：提取子模块，将Circuit的功能拆分为多个独立的类 / 接口，比如可以多加一个工厂类，承担组件管理创建。加一个计算类承担输出计算、排序功能等。
2.注释占比少可读性差
当前问题：注释占比过低，方法 / 变量命名可能不直观（如Yor类名无法直接理解含义），后续维护者难以快速上手。
改进方案：通过注释、命名、测试等规范，保证代码的可读性和可维护性
- Circuit核心类臃肿
二. 数字电路模拟程序-2
-
题目
在数字电路模拟程序-1的设计基础上进行迭代设计，数字电路模拟程序2- 包含多输入输出的组合电路元件如数据选择器；
- 元件引脚类型除输入、输出之外，增加控制引脚，如三态门。
-
设计与分析：
- 类图设计：如下图
![image]()
- 代码分析：
![屏幕截图 2025-12-14 202145]()
![屏幕截图 2025-12-14 202308]()
1）. 整体代码规模：显著膨胀
-
总行数：1178 行（之前是 420 行）；
-
有效代码（Statements）：652 行（之前是 240 行）；
类 / 接口数量：12 个（之前是 8 个）； -
方法总数：74 个（之前是 33 个），平均每个类有 6.17 个方法，每个方法平均 8.59 行代码。
→ 代码量几乎是之前的3 倍，但类和方法的增长比例更高，说明系统功能在快速扩展，但也增加了维护压力。
2）.复杂度与嵌套深度：风险极高 -
最大复杂度：141（之前是 6），对应方法getInputPinCount().getControlPinCount()；
-
最大嵌套深度：9+（之前是 7），位于第 819 行，且9+深度的代码占了 241 行（近 40% 的有效代码）；
-
平均复杂度：6.72（之前是 1.81），平均嵌套深度：5.81（之前是 1.77）。
→ 无论是局部方法还是整体代码，复杂度和嵌套深度都远超合理范围（行业通用阈值：复杂度≤10、嵌套深度≤3），代码可读性、可维护性已严重下降，后续修改极易引入 Bug。
3）.方法级风险：核心方法过于臃肿 -
从 “最复杂方法” 列表可看到多个高危方法：
getInputPinCount().getControlPinCount()：
复杂度 141、代码行数 33、嵌套深度 19、方法调用 6 → 极度臃肿，逻辑高度耦合；
Multiplexer.setPinValue()：
复杂度 54、代码行数 89、嵌套深度 11、方法调用 53 → 方法体过长，调用链极复杂；
Main.main()：
复杂度 7、代码行数 21、嵌套深度 4、方法调用 13 → 相比整体风险已不算突出，但仍是入口逻辑的潜在瓶颈。
4）.分支与注释：分支密集，注释不足 -
分支语句占比：22.2%（与之前接近），但代码量翻倍后，实际分支数量大幅增加，逻辑更复杂；
-
注释占比：15.4%（之前是 7.1%）→ 虽有提升，但仍低于 20% 的合理阈值，核心复杂方法的注释可能缺失。
-
采坑心得：因为类的设计没有做出太大改变，迭代设计时代码修改范围极大，基本各个核心方法都改了，采坑心得核心：类设计缺乏抽象接口层和模块化拆分，导致迭代时只能修改核心方法，而非扩展新代码；核心类职责臃肿，违反单一职责原则，牵一发而动全身。
-
改进建议：
改进建议核心基于开闭原则抽象接口层，用接口固定通用逻辑，具体实现类承载易变逻辑；拆分核心类职责，用工厂模式、配置驱动隔离变化点，让迭代时的修改范围仅限于新增 / 修改独立模块；建立迭代规范，优先通过 “扩展” 实现需求，而非 “修改” 原有核心代码。
三.总结
通过本次数字电路模拟程序的两次迭代开发，我深刻体会到：
- 软件工程基本原则的重要性
◦ 单一职责原则：第一次设计时Circuit类过于臃肿，导致第二次迭代时修改范围过大
◦ 开闭原则：缺乏抽象接口层，无法做到"对扩展开放，对修改关闭"
◦ 依赖倒置原则：高层模块直接依赖低层细节，导致耦合度过高 - 复杂度控制的必要性
◦ 第一次作业时复杂度尚可接受（平均1.81）
◦ 第二次作业复杂度急剧上升（平均6.72），其中最高达141，已严重超出合理范围
◦ 认识到代码复杂度不仅影响可读性，更直接影响后续维护成本 - 设计模式的实际应用价值
◦ 工厂模式：用于创建不同元件对象
◦ 策略模式：不同元件的计算逻辑可以抽象为算法策略
◦ 观察者模式：信号传播可采用事件驱动方式 - 迭代开发的经验教训
◦ 第一次设计时应考虑后续扩展性
◦ 核心逻辑应抽取到独立模块，避免与具体业务逻辑耦合
◦ 通过合理的抽象，将易变部分与稳定部分分离
这次项目让我认识到：
- 设计优于编码：花在前期设计的时间，能显著减少后期修改的成
- 简单优于复杂：过度设计会增加理解难度，但缺乏设计会导致维护灾难
- 抽象是关键能力：能否从具体问题中提取通用模式，是软件工程师的核心能力
- 重构需要勇气：面对已经"能用"但设计糟糕的代码，要有勇气和决心进行重构