OOP作业集4~6总结

一、前言
本次面向对象程序设计课程三次作业集，以数字电路仿真系统为场景展开。让学生通过迭代式的训练，题目将需求一步一步地增加和细化，使得电路仿真功能更加完善，从作业四的基础五类逻辑门电路，到作业五新增四类复合器件电路，补充控制引脚、高阻无效电平，能够适配多类型受控元器件仿真，更加贴合真实硬件电路运行场景。作业六就让代码更加提升系统的可行性和真实可靠性，明确了现实当中电路存在子电路封装复用、多层嵌套连线的实际场景，同时引进了电路连接异常校验、信号迭代稳态判定、全局元件工厂创建等工程化概念以及固定运算优先级常量，使得电路仿真计算更加科学严谨。
知识点的考察也和题目需求息息相关，随之迭代升级。第四次作业提出了软件设计原则，以下所有的代码都要建立在这些原则之上。同时考察正则解析输入文本的细节，稍有不注意，就会出现语句匹配失败、元件解析异常的问题，因此需要规范正则表达式编写规则，精准匹配不同格式的输入语句。
第五次作业在第四次作业的基础上细化了引脚层级划分要求，增加了专用输入校验模块、差异化输出模块，考察类的职责分离，通过类间协作来实现复合器件电路仿真功能，难度较第四次明显加大；第六次作业继续迭代，引入子电路容器实体，新增基于组合模式的树形电路结构搭建、多优先级异常连接校验功能，增强程序鲁棒性要求，类间关系的复杂度增加也就导致思维难度的提高，是面向对象设计原则与三大设计模式的综合考察。
二、设计与分析
第四次作业设计与源码分析
（1）通过SourceMonitor的生成报表内容来分析：

1.分支语句占比20.0%：初代电路仿真需要大量引脚校验与信号迭代判断，分支代码占比较高，整体基础业务逻辑判定偏多。
2.代码总调用次数90次：方法调用频次适中，代码复用合理，类间无过度耦合与循环调用问题。
3.工具检测识别20个类：业务类划分完整无冗余，但所有类集中在单个源文件，项目目录结构杂乱。
4.类平均方法数11.45、单方法平均语句1.20条：单类承载方法过多，违背单一职责原则；同时方法拆分过细，存在大量冗余短小的get/set工具方法。
5.最大圈复杂度为12：存在一处高风险复杂代码，集中在信号迭代与引脚多层校验逻辑，分支繁杂，bug排查难度较高。
6.最大嵌套深度6层：代码嵌套层数远超行业3层标准，多层循环与条件判断叠加，代码可读性差，易出现逻辑疏漏。
7.平均嵌套深度为2.27层，代码平均圈复杂度2.31：代码整体平均复杂度表现良好，仅局部代码出现腐化问题，整体代码质量处于合格水平。
（2）通过PowerDesigner类图来进行分析：

第四次作业搭建分层代码架构，按业务职责划分模块实现模块解耦，本次UML类图涵盖泛化、实现、组合等类间关系，通过抽象父类、接口多态优化代码冗余，借助不同类间关系完成模块协作；结合类图可完整梳理电路仿真全流程，整套设计严格遵循开闭原则、单一职责原则等面向对象设计准则，有效降低代码耦合度、提升复用性，也为后续两次迭代作业筑牢了代码设计基础。
第五次作业设计与源码分析
（1）通过SourceMonitor的生成报表内容来分析：

1.分支语句占比21.9%：较第四次作业小幅上涨，新增引脚校验、电平判定等逻辑，条件分支增多，代码整体逻辑复杂度有所提升。
2.最大圈复杂度27：相比上次近乎翻倍，远超高危代码阈值，多引脚信号校验方法堆砌大量分支语句，代码调试难度大，易出现边界漏洞。
3.最大嵌套深度7层：嵌套层级继续增加，远高于行业标准，多层判断叠加导致代码可读性变差，容易出现逻辑遗漏。
4.平均嵌套深度2.38、平均圈复杂度2.67：项目整体指标小幅上升，大部分代码逻辑依旧简洁，整体代码质量变差仅由单个高危臃肿方法导致，存在明显局部代码腐化问题。
（2）通过PowerDesigner类图来进行分析：

第五次作业新增四类复合器件，将代码重构为五层分层架构，按业务职责划分模块实现全链路解耦，类图涵盖泛化、实现、组合、关联、依赖五类标准UML关系，契合面向对象建模规范与电路自上而下的仿真逻辑。以顶层抽象类与运算接口搭建项目核心框架，借助继承、多态统一元器件运算调度逻辑，引脚、信号等实体承载基础硬件数据，各类工具类分工明确、各司其职，主类仅负责流程串联，全程恪守单一职责原则；同时五类类间关系分工明确，分别实现类的继承拓展、接口规范、强绑定关联、数据交互与工具调用，完整支撑整套电路仿真系统的内部协作。
第六次作业设计与源码分析
（1）通过SourceMonitor的生成报表内容来分析：

1.分支语句占比23.2%：该项指标连续三次作业持续上涨，受异常校验、子电路匹配等新增逻辑影响，条件判断代码进一步增多，整体代码逻辑复杂度稳步抬升。
2.最大圈复杂度19：相较第五次作业大幅下降，本次迭代拆分了部分冗余分支代码，复杂度得到优化，但依旧处于高危区间，核心业务方法仍需进一步重构。
3.最大嵌套深度9层：嵌套层数连续三次递增，受子电路递归、多级异常判断影响，代码嵌套程度持续加深，远高于行业标准，代码可读性较差。
4.平均嵌套深度2.44、平均圈复杂度2.90：项目整体平均复杂度小幅上升，整体代码质量依旧分化，大部分代码逻辑简洁，整体复杂度依旧由局部高复杂度方法拉高。
（2）通过PowerDesigner类图来进行分析：

第六次作业在前两次基础上迭代升级，新增子电路嵌套、异常校验等工程化功能，本次设计核心亮点为落地三大面向对象设计模式：采用组合模式实现子电路多层嵌套复用，依托简单工厂模式统一元件创建流程，利用模板方法模式复用通用运算逻辑，有效精简冗余代码。本次迭代类与接口数量增至29个，全面践行多项面向对象设计原则，进一步降低代码耦合度。对比前两次作业，项目架构更完善、代码工程化程度更高，但仍存在静态代码不规范、子电路耦合偏高、缺少自定义异常等问题，后续可从代码封装、异常体系两方面继续优化。
三、踩坑心得（附带预期输出和问题输出对比图）
第四次作业踩坑：
1.信号缓存只新增不覆盖，电平信号无法动态刷新问题，初始编写的信号缓存方法仅支持新增信号记录，上游电平变化后缓存依旧保留旧值，多级串联电路运算全部出错，后来重构updateBuffer方法，先判断信号是否存在，存在则覆盖更新、不存在再新增缓存，解决旧值残留问题。

2.元件遍历无序，违背硬件电路时序问题，初期直接遍历集合执行运算，无优先级排序，前置依赖电路无法正常运算，后续新增自定义冒泡排序，严格按照元件固定优先级+编号排序，匹配真实电路逐级运算时序。

3.接口与抽象类过度设计问题，初期冗余新增独立逻辑门接口，形成双层约束结构，拉高代码复杂度，后续删除多余接口，仅保留顶层抽象类+运算接口双层规范，简化整体代码结构。
第五次作业踩坑：
1.初期代码混淆引脚排布顺序，错误将输入引脚放置在控制引脚前方，和题目标准引脚顺序颠倒，受控复合器件全部运算失效，后续全局固化引脚排布规则：控制引脚→输入引脚→输出引脚，全局统一不再自定义顺序。

2.无效电平判断缺失，引脚悬空未做空值防护，引脚无输入时程序默认电平为0，不符合题目屏蔽无效元件输出的要求，后续所有元件运算前置空值校验，存在悬空引脚直接屏蔽输出结果。
3.Main主类职责高度混杂，初期编写代码违背单一职责原则，将输入解析、信号迭代、器件运算、输出打印全部写在Main类中。后来拆分输出打印工具类、信号调度类，剥离主类冗余逻辑，使得Main类仅负责输入读取与流程调度，符合单一职责原则。
第六次作业踩坑：
1.静态变量滥用导致上下文污染问题，GateFactory工厂静态集合缓存已创建元件，多轮仿真运行时历史数据不会自动清空，合法元件被误判为重复创建，后续新增reset重置方法，每轮仿真开始前清空静态缓存，保证运行环境独立干净。
2.异常校验判断顺序错误，违背题目给定优先级，初期并行判断五类连接异常，或是颠倒判断顺序，多异常同时出现时输出错误文案不符要求，后续严格按照题目固定优先级串行编写判断分支，高优先级异常命中后直接终止后续判断。

3.主观新增多余业务锁逻辑，错误增加引脚占用锁集合，限制引脚仅能赋值一次，违背组合电路电平可实时刷新的硬件原理，后续直接删除引脚锁定集合，还原真实电路信号流转逻辑。
4.子电路前缀拼接缺失，多层嵌套元件全局名称不唯一，信号处理器无法寻址匹配元件，后续每层子电路递归拼接完整名称前缀，保证全局所有元件、引脚标识唯一。
四、改进建议
第四次作业改进：
1.元件引脚集合直接返回原始集合引用，外部可随意修改引脚内容，破坏封装性。优化后返回集合新副本，仅对外提供只读访问能力，保护内部核心数据。
2.规范方法与变量命名，将无序方法、变量统一遵循小驼峰命名法，做到见名知意，统一全文编码规范。
3.删除不必要的Setter方法，电路引脚、元件基础属性初始化后无需外部修改，杜绝外部非法篡改内部数据。
4.拆解高复杂度嵌套代码，拆分圈复杂度12、嵌套6层的核心方法，精简多层分支与循环嵌套，降低代码阅读与调试难度。
5.合并大量行数过短的get/set工具方法，减少单类方法数量，缓解单类职责过载问题。
第五次作业改进：
1.器件判定方法统一添加is前缀，将无返回提示的判定方法重构为isXXX格式，比如isPinReady、isComponentValid，见名知意，提升代码可读性。
2.统一封装引脚获取通用方法，将重复的根据名称查找引脚的代码抽离为公共工具方法，减少代码冗余。
3.输出格式字符串模板化，将多类器件固定输出格式存入常量，后续修改输出格式无需改动核心业务代码。
4.重构高危复杂业务方法，拆分圈复杂度27、七层嵌套的臃肿代码，拆解多层分支与循环，降低代码调试难度。
第六次作业改进：
1.残留少量未调用冗余测试代码，包括早期引脚锁定相关方法、废弃旧版信号缓存方法，统一清理删除无用代码，精简项目整体结构。
2.职责耦合问题优化，原解析类中耦合异常校验逻辑，优化后解析类只负责文本语句拆分，校验类独立完成异常检测，彻底解耦两大模块，严格遵循单一职责原则。
3.魔法字符串与魔法数字过多，将所有错误提示文案、元件排序优先级、迭代最大次数全部抽离至全局常量类，统一管理所有固定参数。
4.子电路构建长方法拆分，将build构建方法拆分为引脚初始化、内部语句解析、子元件创建三个子方法，降低单个方法圈复杂度。
5.二次优化高复杂度核心方法，拆分圈复杂度19、八层嵌套的业务代码，逐层拆解深层分支与循环嵌套，将嵌套层数降至行业标准范围内。
五、总结
心得收获：
1.写代码前必须正确理解硬件业务需求，不能主观臆造业务规则，贴合真实硬件电路运行逻辑才能保证仿真程序结果准确。
2.彻底区分了组合、聚合、依赖三者的核心差异，能够根据业务场景精准实现类间关系，能够对照UML类图自上而下搭建项目代码架构。
3.落实封装性编码要求，核心引脚数据、内部元件集合必须私有化隐藏，通过统一对外接口访问，杜绝权限泄露与外部非法篡改。
4.理解了静态变量在仿真程序中的使用坑点，多轮独立运行的仿真项目需要谨慎使用静态集合，必须配套重置方法避免上下文残留污染。
5.深刻理解了必须遵循单一职责原则，复杂业务一定要拆分模块与工具类，让每一个类、每一个方法只负责一件事，简化主流程代码，降低调试难度。
6.掌握组合模式、工厂模式落地场景，理解树形嵌套结构适配组合模式，统一对象创建流程适配工厂模式，学会按需选用设计模式而非生硬套用模板。
进一步学习和研究：
1.补齐全文档关键代码注释，规范注释格式，后续编码杜绝零注释代码，同时精简无用get/set方法，坚持规范命名，做到代码自解释。
2.系统学习更多结构性、创建型设计模式，对比组合模式、工厂模式的适用场景，完善设计模式知识体系。
3.持续优化代码圈复杂度与嵌套深度，优化循环与分支结构，尽量将嵌套层数控制在行业3层最佳标准以内。
4.强化需求优先级意识，不擅自调整判断逻辑与执行顺序，保证程序完全贴合题目输出规范。
5.坚持先建模、后编码的开发流程，复杂迭代项目提前绘制UML类图、流程图，梳理清类间关系之后再编写代码，从源头优化代码架构。