面向对象设计与构造-三次题目集总结（2）

前言

三次作业集的知识点
1.组合模式设计：将基本门电路与子电路统一抽象为元件类，支持层级嵌套与统一调用。
2.拓扑信号传播：基于队列的广度优先传播机制，按依赖顺序逐级计算元件输出。
3.分级异常校验：按优先级逐行检测连接异常，仅输出首个最高优先级错误。
4.子电路模板复用：子电路作为可实例化模板，多实例间元件与信号完全隔离。

设计与分析

第一次题目集的详细报表和类图

详细报表提供的数据
基础规模：403 行代码、207 条语句，仅 6 个类，平均每个类 4 个方法；注释覆盖率仅 0.7%，几乎无注释可读性差。
复杂度风险：全局平均圈复杂度 3.17，是三份文件最高；核心方法Gate.compute()复杂度 16（全项目峰值）、Circuit.calculate()复杂度 11，深层嵌套多，最大代码块深度 6，平均块深度 2.44，分支语句占比 23.2%，大量条件逻辑极易产生 bug、难以单元测试。
结构缺陷：单方法平均语句 6.46 行，业务逻辑过度堆砌；方法调用 47 处，耦合偏高；代码块直方图高深度区间占比偏高，嵌套层级深，维护、重构成本大。
类图解释
核心分层与职责
仅 4 个核心单元：Main主程序、静态内部类Gate、枚举GateType，无独立组件 / 信号拆分。Gate作为静态内部类依附Main，仅实现基础与 / 或 / 异或等门类型；GateType枚举统一管理门电路类型。
耦合与设计缺陷
高耦合：Main直接聚合全部Gate实例，解析、电路运算、入口逻辑全部堆在Main，对应代码度量里平均复杂度 3.17、最高复杂度 16，Gate.compute()方法逻辑臃肿。
扩展性极差：仅支持基础逻辑门，无子电路、多路选择器、译码器等扩展元件，无独立信号类，输入输出信号直接存在Gate内部字段，职责混杂。
封装薄弱：核心运算、解析、实例创建全部写在Main，无工厂、无分层，所有业务逻辑集中在入口类，维护、新增元件需要大幅修改Main。
适用局限
仅能实现简单单层门电路，无法处理复杂嵌套电路，类数量仅 6 个，功能极简，是最原始原型。
心得
缺乏分层抽象的设计会带来连锁负面效果：架构上职责混杂、类与类强耦合，代码层面直接体现为方法臃肿、圈复杂度飙升、嵌套层级过深。当后续需要新增译码器、多路选择器，或是实现可复用子电路时，初代架构只能大规模修改 Main 与 Gate 核心代码，扩展性极差。

第二次题目集的详细报表和类图

详细报表提供的数据
基础规模：391 行、422 条语句，12 个类，每类平均 7 个方法；注释覆盖率 0%，完全无注释，可读性短板突出。
复杂度改善：平均圈复杂度降至 1.76，整体逻辑大幅简化；最高复杂度方法为Circuit.getComp()（复杂度 13），其余方法复杂度普遍≤8；最大代码块深度 7，平均块深度 1.97，分支语句占比仅 14.9%，条件分支大幅减少。
结构变化：单方法平均 3.46 行，拆分更细、单一职责更好；方法调用 61 处；代码块深度集中在低区间，嵌套逻辑少，相比 works1 大幅降低调试难度，但类数量翻倍，存在类分散、无注释的维护问题。
类图解释
架构升级：单一职责拆分
拆分出三大独立实体：Main全局管理器、Component通用元件基类、Signal信号实体，彻底剥离初代Gate的臃肿职责。
Component抽象所有电路元件，统一持有引脚、输入输出映射、校验与求值方法，所有门电路统一复用该类；
Signal单独封装信号传递数据（目标元件、引脚、信号值），实现数据与运算分离；
Main改用静态 Map 全局管理元件与连线，提供统一创建工具方法。
设计改进点
解耦完成：门电路数据、信号数据、全局管理三类完全分离，对应代码度量平均复杂度降至 1.76，单方法平均语句从 6.46 降到 3.46，方法拆分更细；
统一抽象：所有逻辑元件共用Component基类，新增元件无需改动全局主类；
控制流简化：最大代码块深度 7 但平均块深度仅 1.97，分支语句占比 14.9%，大量 if 嵌套被封装到独立组件方法。
遗留短板
仍缺少子电路、元件工厂，没有译码器 / 多路选择器等复合元件，仅支持单层电路，无法实现分层嵌套电路；没有统一元件创建工厂，元件实例化逻辑散落在Main中。
心得
结合 works2.java 的静态度量报表与第二版分层类图对比分析，我直观感受到面向对象拆分重构对代码质量带来的显著改善，也清晰认识到分层解耦设计能有效降低代码复杂度。

第三次题目集的详细报表和类图

详细报表提供的数据
基础规模：662 行、683 条语句，三份文件体量最大；14 个类，每类 7.21 个方法；注释覆盖率依旧 0%，无文档注释是统一短板。
复杂度控制：平均圈复杂度 1.77，与 works2 接近，整体复杂度稳定可控；最复杂方法Circuit.parseSubCircuitLine()复杂度 10，峰值复杂度低于 works1/works2；最大代码块深度 6，平均块深度 1.82，嵌套层级最低，分支占比 21.7%，新增子电路解析逻辑带来少量分支，但控制良好。
扩展特征：单方法平均 6.31 行，新增大量解析、子电路业务代码；方法调用 133 处，模块交互更多；代码块直方图基数大幅提升，新增功能模块，但高深度嵌套极少，代码分层清晰，在功能扩充的同时维持了较低复杂度，工程结构最优。
类图解释
完整分层架构（五层结构）
入口层：Main，负责文件解析、子电路顶层调度；
电路管理层：Circuit，全局电路容器，管理元件、连线、外部输入；
模板层：SubCircuit子电路模板，支持嵌套复用电路，实现模块化；
工厂层：ComponentFactory，统一元件创建入口，完全消除实例化耦合；
元件实现层：抽象父类Component + 全部专用元件（AndGate、Decoder、Mux、Demux、TriState 等），每种元件独立实现compute()求值逻辑。
成熟设计优势
工厂模式落地：ComponentFactory.createComponent()统一生成所有元件，新增元件仅新增子类，无需修改上层解析代码；
子电路复用：SubCircuit封装可复用电路模板，支持多层嵌套，工程复用能力拉满；
完全开闭原则：扩展新门、新复合元件只新增Component子类，Circuit/Main几乎不用改动；
复杂度可控：代码体量达到 662 行（三倍于初代），但平均复杂度维持 1.77，峰值复杂度 10 低于前两版，新增大量业务逻辑却没有出现巨型复杂方法。
心得
第一，优秀的面向对象架构可以在大量扩充业务功能的同时，有效控制代码复杂度，不会随着需求迭代出现代码腐烂；第二，工厂模式、模板封装等设计模式不只是理论概念，能切实解决代码耦合、扩展困难的工程问题；第三，代码度量指标可以直观验证架构设计好坏，即使代码行数大幅增加，只要做好分层拆分、职责隔离，圈复杂度、嵌套深度等关键指标依旧能维持在健康区间；第四，完整工程化设计仍存在细节短板，全文件无注释会削弱架构优势，后续开发需要补充注释规范，完善代码文档。整体而言，这个版本是三次迭代里设计最完善、工程化程度最高的实现，也让我掌握了 “架构设计 + 静态指标” 相结合的代码评估方法。

踩坑心得

踩坑与反思
初期未做分层抽象，把解析、运算、管理全塞进 Main，单方法逻辑堆积，圈复杂度居高不下，多层嵌套极易写错逻辑，调试耗费大量时间。
第二版拆分 Component、Signal 解耦后，虽降低复杂度，但缺少工厂类与子电路模板，新增译码器、嵌套电路时仍要大幅修改核心代码，扩展性不足。
全程未写注释，三份文件注释覆盖率几乎为 0，回看旧代码时很难快速理清类之间依赖关系，增加维护成本。
前期忽视静态度量指标，只追求功能实现，等到方法行数、分支数量超标才重构，返工成本更高。

改进建议

1.规范注释编写，补充类、核心方法说明，提升代码可读性。
2.持续控制方法圈复杂度，拆分超长、多分支的逻辑函数。
3.完善异常处理与参数校验，优化子电路解析分支逻辑。
4.统一封装工具方法，减少重复代码，进一步降低类间耦合。
5.建立代码自查习惯，借助静态度量指标提前规避代码腐化。

总结

本次三次迭代完成了门电路程序从简易原型到工程化分层架构的优化，通过拆分实体、引入工厂与子电路模块，在扩充大量功能的同时有效控制了代码圈复杂度、嵌套深度。但全版本缺失注释、前期架构规划不足等问题暴露明显。后续开发应先做好面向对象分层设计，利用代码度量工具把控代码质量，同步完善注释文档，提前预留功能扩展接口，减少后期重构返工。