面向对象程序设计——数字逻辑电路仿真单元总结

写在前面

本单元一共完成三次数字逻辑电路仿真作业，作业难度循序渐进。从最基础的五种逻辑门电路仿真，迭代到中规模器件扩展，最后完成支持子电路实例化与嵌套的组合模式架构。在完成作业的过程中，我慢慢熟悉了 Java 面向对象的编写方式，弄懂了封装、继承、组合、单一职责等基础设计思想。同时我学会使用 PlantUML 绘制类图、使用 SourceMonitor 查看代码数据，直观找出代码存在的问题。本文结合三次作业源码、类图以及代码分析报表，记录我的编写过程、出现的问题以及优化反思。

一、Complexity Metrics（复杂度分析）

为直观量化代码质量，本单元使用 SourceMonitor 工具对代码进行度量分析，本文主要参考以下指标：

• v(G)圈复杂度：衡量程序分支路径数量，数值越大代表if、for、while判断越多，代码可读性越差，维护难度越高。
• iv(G)设计复杂度：衡量方法之间耦合程度，数值越高说明该方法调用关联方法过多，耦合严重。
• ev(G)基本复杂度：衡量代码结构化程度，判断是否存在冗余嵌套、病态结构。
• WMC类总复杂度：一个类内部所有方法复杂度总和，反映类的臃肿程度。
• OCavg类平均复杂度：类中单个方法的平均复杂度，用于判断类设计是否均衡。

注：SourceMonitor 对 Java 语言的方法级度量默认仅输出圈复杂度 v (G)，本文分析以圈复杂度为核心依据。

二、三次作业设计与分析

2.1 作业 4：基础门电路仿真程序

2.1.1 作业要求

作业 4 为单元入门作业，要求实现与门、或门、非门、异或门、同或门五种基础逻辑门的功能仿真。程序需读取文本格式的电路描述文件，解析器件定义、引脚连接关系，通过迭代法实现信号传播，最终输出所有引脚的稳定电平值。本次作业重点练习类的继承与封装，初步建立面向对象的设计思维。

2.1.2 程序结构与类图

本次作业共设计 6 个类：抽象父类Gate、五个具体门电路子类（AndGate、OrGate、NotGate、XorGate、XnorGate）以及主程序类Main。

Gate抽象父类封装了所有门电路的通用逻辑：引脚集合管理、输入信号写入、输出信号读取、状态判断等通用方法，并声明抽象的calculate()方法作为统一计算接口。每个具体门电路子类继承Gate父类，重写calculate()方法实现各自的逻辑运算规则。Main类负责文件读取、器件实例化、引脚连接建立、迭代信号传播以及结果格式化输出。整体采用经典的继承架构，父类抽象通用能力，子类实现差异化逻辑，符合面向对象 “开闭原则” 的雏形。

2.1.3 代码规模与度量分析

本次作业整体代码规模较小，共 7 个 Java 源文件，总代码量 306 行，有效语句 202 条，整体注释率 4.2%。通过 SourceMonitor 生成的检查点汇总数据如下：

各文件的详细度量数据如下表所示：

File Name	Lines	Statements	% Branches	Calls	% Comments	Classes	Methods/Class	Avg Stmts/Method	Max Complexity	Max Depth	Avg Depth	Avg Complexity
Work1\AndGate.java	24	15	20.0	3	0.0	1	3.00	2.67	4	4	1.60	2.00
Work1\Gate.java	52	30	6.7	6	11.5	2	2.00	3.50	5	4	1.50	2.00
Work1\Main.java	142	102	29.4	45	4.9	1	2.00	21.50	16	7	2.03	16.00
Work1\NotGate.java	19	12	8.3	3	0.0	1	3.00	1.67	3	2	1.25	1.67
Work1\OrGate.java	25	15	20.0	3	0.0	1	3.00	2.67	4	4	1.60	2.00
Work1\XnorGate.java	22	14	7.1	4	0.0	1	3.00	2.33	3	2	1.36	1.67
Work1\XorGate.java	22	14	7.1	4	0.0	1	3.00	2.33	3	2	1.36	1.67

从数据可以看出，代码量与复杂度高度集中在Main.java文件，其余门电路子类代码量少、复杂度低，呈现明显的 “主类臃肿、子类轻薄” 的特征。

2.1.4 复杂度分析

方法级的核心复杂度分布如下表所示：
表格

方法	圈复杂度 v(G)	说明
Main.main()	16	集成了解析、迭代、输出全流程，嵌套循环+多分支，是复杂度最高的方法
Gate.setInput()	5	引脚范围校验+旧值对比，负责输入信号写入与状态更新
AndGate.calculate()	4	单循环遍历引脚，遇0短路退出，逻辑简洁
OrGate.calculate()	4	单循环遍历引脚，遇1短路退出，分支逻辑合理
NotGate.calculate()	3	单分支取反逻辑，复杂度极低

整体来看，所有门电路子类的计算方法复杂度均控制在 4 以内，职责单一，符合继承设计的预期。复杂度全部集中在主类的main方法中，原因是初次编写时未进行方法拆分，将文件解析、信号迭代、结果输出全部耦合在同一方法内，导致单方法体量过大。类级维度上，Main类的平均圈复杂度达到 16，远高于其他类，职责分配严重不均衡。

2.1.5 作业优缺点总结

优点：基础继承架构设计合理，父类抽象通用逻辑，子类实现差异化运算，代码复用性较好；门电路子类职责单一，扩展新器件时仅需新增子类，对原有代码侵入性低；信号迭代逻辑清晰，基础功能稳定可靠。
缺点：主类职责严重过载，所有流程逻辑耦合在 main 方法中，可维护性差；未进行方法拆分，单方法圈复杂度过高；缺少输入合法性校验，非法输入会直接导致程序崩溃；注释率偏低，核心逻辑缺少说明。

2.2 作业 5：中规模器件扩展

2.2.1 作业要求

作业 5 在作业 4 的基础上进行功能扩展，新增译码器、数据分配器、数据选择器、三态门四种中规模器件，同时统一引脚编号规则，增加输出有效性判断机制。本次作业的核心目标是验证继承架构的扩展性，练习在已有代码基础上进行增量开发，同时提升程序的健壮性。

2.2.2 程序结构与类图

本次作业沿用作业 4 的继承体系，在Gate父类基础上新增四个器件子类（Decoder、Demux、Mux、TriStateGate），每个类独立实现自身的calculate()计算逻辑。主类中拆分出createGate()方法，专门负责根据器件类型创建对应实例，减轻 main 方法的负担。

得益于合理的继承设计，原有五个基础门电路类几乎零修改即可直接复用，新增器件仅需新增子类并重写计算方法，充分体现了面向对象 “开闭原则” 的优势 —— 对扩展开放，对修改关闭。但器件创建逻辑仍耦合在主类中，随着器件类型增加，分支判断持续膨胀。

2.2.3 代码规模与度量分析

本次作业代码量显著提升，源文件数量增加到 11 个，总代码量约 550 行，整体注释率略有提升。SourceMonitor 检查点汇总数据显示，全项目最大圈复杂度上升至 43，整体平均圈复杂度为 2.55。

核心文件的详细度量数据如下：

File Name	Lines	Statements	% Branches	Calls	% Comments	Classes	Methods/Class	Avg Stmts/Method	Max Complexity	Max Depth	Avg Depth	Avg Complexity
Work2\AndGate.java	31	20	15.0	5	0.0	1	4.00	2.75	4	4	1.60	1.75
Work2\Decoder.java	64	34	14.7	9	9.4	1	5.00	5.00	6	3	1.56	4.50
Work2\Demux.java	65	37	21.6	12	7.7	1	5.00	5.80	5	3	1.49	3.50
Work2\Gate.java	78	45	17.8	13	17.9	2	1.50	8.33	8	5	2.71	4.67
Work2\Main.java	208	138	41.3	57	14.4	1	2.00	63.50	43	8	4.41	29.50
Work2\Mux.java	50	29	10.3	9	8.0	1	5.00	3.80	3	3	1.69	1.60
Work2\NotGate.java	26	17	5.9	5	0.0	1	4.00	2.00	3	2	1.35	1.50
Work2\OrGate.java	32	20	15.0	5	0.0	1	4.00	2.75	4	4	1.60	1.75
Work2\TriStateGate.java	31	21	4.8	9	3.2	1	4.00	3.00	3	2	1.48	1.50
Work2\XnorGate.java	29	19	5.3	6	0.0	1	4.00	2.50	3	2	1.42	1.50
Work2\XorGate.java	29	19	5.3	6	0.0	1	4.00	2.50	3	2	1.42	1.50

从数据变化可以看出，新增的中规模器件本身复杂度处于合理区间，复杂度的增长主要集中在主类，主方法的圈复杂度从 16 跃升至 43，增长幅度显著。

2.2.4 复杂度分析

方法级核心复杂度分布如下表所示：

方法	圈复杂度 v(G)	说明
Main.main()	43	器件类型翻倍后，解析与输出分支大幅增加，复杂度达到峰值
Main.createGate()	16	9种器件的创建分支，switch结构随器件新增持续膨胀
Gate.setPin()	8	统一处理控制引脚、输入引脚赋值，包含范围校验与状态更新
Decoder.calculate()	6	使能判断+地址编码+多输出赋值，属于正常业务复杂度
Demux.calculate()	5	控制端译码+单输入分配到多输出，分支逻辑较多

本次作业的复杂度上升符合需求迭代的规律，但也暴露了架构的隐患：主类承担了过多的器件解析与创建职责，每新增一种器件就要修改主类代码，违反开闭原则；同时主方法持续膨胀，圈复杂度突破 40，已经处于较高风险区间，后续迭代必须进行职责拆分。新增器件的计算方法复杂度均控制在 6 以内，说明继承架构对业务逻辑的拆分是有效的，复杂度控制良好。

2.2.5 作业优缺点总结

优点：继承架构扩展性得到验证，新增器件无需修改原有门电路代码，复用性强；器件计算逻辑内聚在各自子类中，职责边界清晰；统一引脚管理规则，代码规范性提升。
缺点：主类职责进一步加重，器件创建与输出逻辑耦合严重，圈复杂度过高；采用硬编码的 switch 分支创建器件，扩展性差，新增器件必须修改主类代码；错误处理机制不完善，引脚越界等异常仅做简单处理，错误提示不明确。

2.3 作业 6：子电路与组合模式

2.3.1 作业要求

作业 6 是本单元综合性最强的一次作业，新增子电路定义、实例化与嵌套调用功能，支持用户自定义子电路并像普通器件一样实例化使用；同时要求实现命名重复、引脚越界、环路检测等五类错误检测机制。本次作业的核心目标是掌握组合设计模式，实现层次化的架构设计，同时提升程序的健壮性与错误处理能力。

2.3.2 程序结构与类图

本次作业对架构进行了较大重构，引入组合模式设计：抽象出Component父类作为统一组件接口，定义信号计算、引脚输入、输出获取等通用方法；普通门电路作为叶子节点继承Component，实现基础运算逻辑；SubCircuit子电路作为组合节点继承Component，内部包含多个子元件与连线，实现递归信号计算与端口映射。同时新增错误检测模块，将校验逻辑从主方法中拆分出来。

组合模式的核心优势在于统一了叶子节点和组合节点的接口：对于外部调用者而言，子电路和普通门电路的使用方式完全一致，无需区分元件类型。子电路支持无限嵌套，内部可以包含其他子电路实例，天然支持层次化电路设计。错误检测逻辑独立封装，主类仅负责调度，职责更加清晰。

2.3.3 代码规模与度量分析

本次作业为本单元代码量最大、结构最复杂的一次，源文件数量增加到 13 个，总代码量约 650 行。SourceMonitor 检查点汇总数据显示，全项目最大圈复杂度为 21，整体平均圈复杂度约 2.8。

核心文件的详细度量数据如下：

File Name	Lines	Statements	% Branches	Calls	% Comments	Classes	Methods/Class	Avg Stmts/Method	Max Complexity	Max Depth	Avg Depth	Avg Complexity
Work4\AndGate.java	17	14	21.4	4	0.0	1	2.00	4.50	4	4	1.71	2.50
Work4\Component.java	70	49	14.3	14	1.4	1	9.00	3.11	4	3	1.65	2.00
Work4\Gate.java	20	9	0.0	1	10.0	2	0.50	3.00	1	2	1.00	1.00
Work4\Main.java	333	239	37.7	118	1.5	1	7.00	29.00	8	8	3.18	6.67
Work4\NotGate.java	13	10	10.0	4	0.0	1	2.00	2.50	3	2	1.30	2.00
Work4\OrGate.java	17	14	21.4	4	0.0	1	2.00	4.50	4	4	1.71	2.50
Work4\SubCircuit.java	147	109	24.8	48	0.0	1	7.00	11.86	21	8	3.05	5.43
Work4\XnorGate.java	13	10	10.0	5	0.0	1	2.00	2.50	3	3	1.30	2.00
Work4\XorGate.java	13	10	10.0	5	0.0	1	2.00	2.50	3	2	1.30	2.00

从数据可以看出明显的结构变化：最高复杂度从主类转移到了SubCircuit业务类，主类的最大圈复杂度从 43 下降到 8，职责拆分效果显著。

2.3.4 复杂度分析

方法级核心复杂度分布如下表所示：

方法	圈复杂度 v(G)	说明
SubCircuit.copyInstance()	21	子电路深拷贝，包含元件遍历、连线重映射、端口对齐，支持递归嵌套
SubCircuit.operation()	21	组合模式核心，递归调度内部元件信号传播，处理层级端口映射
Main.checkError()	8	错误检测统一入口，多分支校验各类异常
Component.setInput()	4	统一输入接口，包含范围校验与状态标记
AndGate.operation()	4	基础与门计算逻辑，单循环遍历引脚，遇0短路退出

本次作业的复杂度分布发生了结构性优化：最高复杂度从主类转移到了业务类SubCircuit，这是业务逻辑本身的特性决定的 —— 深拷贝、递归传播、端口映射本身就包含较多循环与分支，属于合理的业务复杂度。主类复杂度大幅下降，单方法最高复杂度仅为 8，说明职责拆分效果显著，符合单一职责原则。所有基础门电路的复杂度与前两次作业基本一致，体现了组合模式对底层元件的零侵入优势，扩展性极强。

2.3.5 作业优缺点总结

优点：采用组合模式实现子电路功能，架构设计优雅，扩展性与复用性大幅提升；主类职责得到有效拆分，复杂度显著下降，代码结构更加均衡；错误检测模块独立封装，程序健壮性提升；面向对象设计思想体现充分，封装、继承、多态、组合模式综合应用。
缺点：SubCircuit的两个核心方法复杂度偏高，可进一步拆分；递归调用未做深度限制，极端嵌套场景可能出现栈溢出；错误检测粒度较粗，部分异常场景提示信息不够精准。

三、三次作业迭代对比分析

3.1 代码结构迭代变化

三次作业的架构演进呈现清晰的进阶路径：
作业 4 采用基础继承架构，仅实现简单的父类抽象与子类实现，主类臃肿，偏向 “面向过程 + 对象” 的写法；
作业 5 沿用继承体系扩展器件，验证了架构的扩展性，但主类职责持续膨胀，架构瓶颈显现；
作业 6 引入组合模式进行架构重构，拆分主类职责，封装错误检测模块，代码分层明确，真正体现了面向对象的设计精髓。

3.2 复杂度变化趋势

随着作业迭代，总代码量持续增加，但复杂度的分布逐步优化：
作业 4 复杂度高度集中在主类，单方法圈复杂度 16；
作业 5 主类复杂度进一步攀升至 43，达到峰值(关键原因在于其继承了作业4的部分方法，导致有些代码冗余）；
作业 6 通过职责拆分与架构重构，主类最高复杂度降至 8，整体复杂度分布更加均衡。
这一变化说明，代码总量增加并不必然导致复杂度失控，合理的架构设计与职责拆分能够有效控制代码复杂度，提升可维护性。

3.3 存在的共性问题

三次作业普遍存在注释率偏低、核心逻辑缺少文档说明的问题；错误处理机制逐步完善，但整体仍偏简单，缺少分层异常体系；器件创建逻辑始终采用硬编码分支，未引入工厂模式进行解耦，扩展性仍有提升空间。

四、采坑心得

本单元三次作业的调试过程中遇到了不少典型问题，很多问题看似诡异，实则都是设计细节考虑不周导致的，以下是印象最深的几个问题与心得。

4.1 信号传播迭代不收敛，程序死循环

作业 4 初次运行时，出现程序启动后无输出、完全卡死的现象，控制台未抛出任何异常。最初误以为是文件读取失败，通过逐步打印定位，最终发现是信号传播的循环终止条件存在缺陷。
问题根源在于两方面：一是部分引脚的初始电平未统一初始化，处于不确定状态，导致信号值在 0 和 1 之间反复跳变，永远无法达到稳定状态；二是终止条件的判断逻辑有误，仅判断了输出引脚的变化，忽略了内部中间引脚的状态更新，导致即使内部信号仍在变化，程序也误判为稳定。
解决方案分为两步：首先为所有引脚设置统一的默认初始电平，消除不确定状态；其次在每轮迭代开始前保存所有引脚的状态快照，一轮计算结束后全量对比新旧状态，若无任何引脚发生变化则立即终止循环。该问题让我深刻认识到，循环终止条件的设计必须严谨，尤其是状态迭代类程序，任何一个状态变量的遗漏都可能导致死循环。

4.2 译码器输入越界，数组下标异常

作业 5 测试译码器功能时，输入 3 位地址的测试用例会抛出数组越界异常，程序直接崩溃。排查后发现两个问题：一是直接用地址值作为下标访问输出引脚数组，没有做范围校验，高位输入直接超出数组长度；二是使能端无效时没有提前返回，仍继续执行后续的输出赋值逻辑。
修复时在计算方法入口增加两层防护：先校验使能端状态，无效时直接将所有输出置为低电平并返回；再校验输入地址的合法范围，超出范围时抛出明确的错误提示。这个问题让我体会到 “防御式编程” 的重要性，任何外部输入都不可信任，必须在方法入口做好参数校验，提前拦截非法情况。

4.3 子电路多实例信号冲突，结果异常

作业 6 实现子电路实例化时，单个子电路单独测试功能完全正常，但同一子电路实例化两次后，输出结果与预期严重不符。经过长时间排查，最终定位到命名冲突问题：实例拷贝时，内部元件和引脚的名称没有做实例化前缀处理，多个实例共享了同一组全局信号名，后创建的实例会覆盖先创建实例的信号值。
解决方案是在copyInstance方法中，对所有内部元件、引脚、连线的名称都添加实例专属的命名前缀，保证每个实例的内部信号完全独立；同时单独维护内外引脚的映射关系，端口连接时通过映射表进行对应，彻底解决命名冲突。这个问题让我对 “实例隔离” 有了更直观的理解，对象的独立性不仅体现在属性封装上，全局命名空间的隔离同样重要。

4.4 嵌套子电路递归调用，栈溢出错误

测试两层以上嵌套子电路时，程序抛出StackOverflowError栈溢出错误。最初以为是电路层级过深，分析代码后发现是递归终止条件存在缺陷：叶子节点的运算方法中错误地加入了向下递归的逻辑，导致递归无法正常终止；同时缺少环路检测，如果子电路出现自引用，递归会无限执行。
修复从两个方向入手：一是明确叶子节点与组合节点的职责边界，门电路叶子节点的运算方法直接执行自身计算，不再向下递归，保证递归深度与电路层级严格一致；二是在子电路实例化前增加环路检测逻辑，遍历依赖关系检查是否存在循环引用，提前抛出错误提示，避免运行时才崩溃。该问题让我对递归的设计原则有了更深的认识：递归必须有明确的终止条件，且每一层调用都要向终止条件靠近。

五、改进建议

结合三次作业的迭代过程与复杂度分析，从架构、性能、健壮性三个维度提出可持续改进的建议。

5.1 架构设计优化：引入工厂模式解耦器件创建

当前器件创建逻辑耦合在主类的createGate方法中，采用 switch 分支判断器件类型，每新增一种器件都要修改主类代码，违反开闭原则。
改进方案：引入简单工厂模式，新建ComponentFactory工厂类统一负责所有器件的实例化；进一步可采用注册表机制，维护 “器件类型 - 构造器” 的映射表，程序启动时注册所有支持的器件类型，新增器件时仅需注册新条目，无需修改仿真核心逻辑。该方案能够彻底解耦器件创建与仿真主流程，大幅提升架构的扩展性。

5.2 性能优化：采用拓扑排序替代全量迭代

当前信号传播采用全量迭代法，每一轮都遍历所有器件重复计算，对于大规模电路时间复杂度为 O (n²)，效率较低，且存在不收敛的风险。
改进方案：改用拓扑排序算法，先根据电路的连接关系构建有向无环图，计算所有器件的拓扑顺序，按顺序单次遍历即可完成全部信号仿真，时间复杂度降至 O (n)。该算法不仅效率更高，而且天然支持环路检测，能够在仿真开始前就识别出非法的环形电路，替代运行时的迭代终止判断。

5.3 健壮性优化：完善异常体系与错误提示

当前错误检测逻辑较为简单，大多采用直接退出程序的处理方式，错误提示信息笼统，定位问题困难；引脚电平采用整数表示，高阻、无效等状态容易出现判断遗漏。
改进方案：自定义分层异常体系，针对引脚非法、命名重复、环路存在等不同错误类型抛出对应异常类，在程序顶层统一捕获并输出精准的错误位置与原因；同时引入Signal枚举类型替代整数表示电平状态，将低电平、高电平、高阻、无效等状态纳入编译期校验，减少运行时的隐藏 bug。通过完善的异常体系，不仅能提升程序的容错能力，也能大幅降低调试成本。

六、总结

6.1 学习收获

本单元三次作业的迭代过程，是我对面向对象设计思想逐步深化理解的过程。从作业 4 只会简单的继承封装，到作业 6 能灵活运用组合模式实现复杂的层次化设计，我逐渐体会到面向对象设计的优势：合理的抽象与分层，能够让代码在需求迭代中保持稳定，避免每次需求变更都推倒重来。
同时，通过 SourceMonitor 的量化分析，我建立了 “代码质量可度量” 的意识：不再仅凭感觉判断代码好坏，而是通过圈复杂度等指标直观识别代码中的臃肿模块，针对性地进行拆分优化。PlantUML 类图的绘制也帮助我养成了 “先设计后编码” 的习惯，在写代码前先理清类与类之间的关系，避免边写边改导致架构混乱。
除此之外，调试能力也得到了很大锻炼。很多没有语法错误的逻辑 bug，需要通过分步测试、日志打印、缩小范围等方法逐步定位，这个过程虽然耗时，但也让我养成了严谨的编码习惯，对边界条件的考虑更加周全。

6.2 自身不足

回顾三次作业，我也清晰认识到自己的不足：一是设计模式的应用还不够熟练，工厂模式、策略模式等常用模式没有主动应用到代码中，很多地方仍采用硬编码的写法；二是代码规范性有待提升，注释书写不及时，变量命名与方法拆分的颗粒度把握不够好；三是测试不够充分，大多只覆盖了正常用例，对边界情况与异常场景的测试不足，很多 bug 都是在调试过程中才发现。

6.3 后续展望

后续我会继续补充设计模式的相关知识，在下次单元作业中主动应用工厂模式、策略模式等设计思想，进一步优化代码架构。同时我会完善测试流程，学习单元测试的编写方法，提升代码的健壮性。对于本单元的电路仿真器，我也计划利用课余时间实现拓扑排序算法优化与工厂模式重构，把本单元学到的知识落到实处。
总体而言，本单元的三次作业让我收获颇丰，不仅提升了 Java 编程能力，更重要的是建立了面向对象的设计思维，学会了用架构的视角看待程序设计。这些知识和经验，都会成为后续学习的坚实基础。