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

前言

三次作业集的知识点

1. 面向对象核心：自定义多类，封装（private 私有属性 + set/get 方法）、无参构造方法
2. ArrayList动态数组
3. 数据校验和合法性检查
4. 模块化思想

设计与分析

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

详细报表提供的数据
平均圈复杂度为1.30，最大圈复杂度为2，平均代码块深度为1.69，最大深度为3平均每个方法包含4.64 条语句，规模适中，所有方法中，复杂度最高的是Main.main()(复杂度为 2），其余方法（如 Cargo、Flight 类的 getter/setter 方法）的圈复杂度均为 1，分支语句占比为 13.3%，方法调用语句占比 14，注释行占比 7.2%。
类图解释
本次作业的类图共包含 Cargo、Flight、LoadManifest、CargoSorter 和 Main 五个类，整体采用实体类、业务类、工具类与入口类的分层结构，职责划分清晰。其中 Cargo 和 Flight 作为数据实体类，分别封装货物与航班的核心属性并提供标准的访问器方法；LoadManifest 作为核心业务类，聚合 Cargo 数组与 Flight 对象，实现货物清单的管理功能；CargoSorter 作为独立工具类，负责货物排序逻辑，通过接收 LoadManifest 实例完成排序；Main 类作为程序入口，统一调度各组件完成整体流程。
心得
本次作业中，我将数据与业务逻辑进行了初步分离：Cargo、Flight 类仅负责封装属性与提供访问器方法，核心业务逻辑集中在 Main.main() 中实现。这一设计使绝大多数方法的圈复杂度维持在 1，仅主方法复杂度为 2，有效降低了代码耦合度，也让我体会到面向对象设计中 “高内聚、低耦合” 的实际价值 —— 通过职责拆分，代码的可读性与可维护性得到了显著提升

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

详细报表提供的数据
本次作业代码经 SourceMonitor 度量，总规模为 476 行，共包含 5 个类、平均每个类有 6.60 个方法，平均每个方法包含 4.94 条语句；平均圈复杂度为 1.14，最大圈复杂度为 3，平均代码块深度为 1.52，最大代码块深度为 4，注释行占比为 13.0%。
类图解释
本次作业类图共包含 Flight、CargoCompartment、Cargo、Position、LoadDispatcher、InputValidator 与 Main 七个类，其中 Flight 与 CargoCompartment 为核心实体类，分别管理航班信息与货舱数据；Cargo 与 Position 为基础数据类，封装货物与位置属性；LoadDispatcher为业务调度类，实现货物排序与货舱查找逻辑；InputValidator 为工具类，提供数据校验功能；Main为程序入口，统一调度各组件。整体采用实体-数据-业务-工具分层结构，职责划分清晰，无循环依赖，符合面向对象封装与低耦合设计原则。
心得
结合本次作业的类图设计与代码度量结果，我对面向对象设计与代码质量控制有了更深入的实践认知。从类图来看，本次作业采用了分层清晰的实体类、数据类、业务类与工具类结构，Flight、CargoCompartment 等实体类封装核心数据与基础方法，LoadDispatcher 承担业务调度逻辑，InputValidator 实现独立的数据校验功能，整体职责划分明确，有效降低了耦合度；而 SourceMonitor 度量数据显示，代码平均圈复杂度为 1.14，最大圈复杂度为 3，平均代码块深度为 1.52，最大深度为 4，说明通过合理的方法拆分与逻辑分层，代码复杂度得到了有效控制，避免了深层嵌套与复杂分支。这次作业让我体会到，面向对象设计的核心不仅是实现功能，更在于通过合理的职责拆分与封装，让代码既满足业务需求，又具备良好的可读性、可维护性与可扩展性，为后续的迭代开发打下了坚实基础。

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

详细报表提供的数据
本次作业代码经 SourceMonitor 度量，总规模为 476 行，平均圈复杂度为 1.14，最大圈复杂度为 3，平均代码块深度为 1.52，最大代码块深度为 4。
类图解释
本次作业的类图共包含 Passenger、Luggage、CargoCompartment、Flight、Position、Cargo、WeightBalanceCalculator、LoadDispatcher、InputValidator 与 Main 十个类，整体采用实体类、业务类、工具类分层设计：Passenger、Luggage、Cargo、Flight 等实体类封装核心数据与基础访问方法，CargoCompartment 管理货舱数据与货物集合，WeightBalanceCalculator 独立实现重量与重心计算逻辑，LoadDispatcher 负责货物调度与货舱匹配，InputValidator 提供输入校验功能，Main 为程序入口统一调度各组件。整体职责划分清晰，无循环依赖，符合高内聚、低耦合的面向对象设计原则。
心得
结合本次作业的类图设计与代码度量结果，我对面向对象设计与代码质量控制有了更深入的实践认知。从类图来看，本次作业采用了分层清晰的实体类、业务类、工具类结构，Passenger、Flight、CargoCompartment 等实体类封装核心数据与基础方法，WeightBalanceCalculator 独立实现重量与重心计算逻辑，LoadDispatcher 承担货物调度功能，InputValidator 提供输入校验，整体职责划分明确，有效降低了耦合度。而 SourceMonitor 度量数据显示，代码平均圈复杂度为 1.14，最大圈复杂度为 3，平均代码块深度为 1.52，最大深度为 4，说明通过合理的方法拆分与逻辑分层，代码复杂度得到了有效控制，避免了深层嵌套与复杂分支。这次作业让我体会到，面向对象设计的核心不仅是实现功能，更在于通过合理的职责拆分与封装，让代码既满足业务需求，又具备良好的可读性、可维护性与可扩展性，为后续的迭代开发打下了坚实基础。

踩坑心得

踩坑与反思
输出格式不规范导致的 “格式错误” 与 “答案错误”是经常出现的。测试点提示 “格式错误”。我发现自己在输出信息时，对提示文字的大小写、标点符号、换行处理不够严谨，比如输出的错误提示信息与题目要求的标准格式存在差异，或是数值保留的小数位数不符合要求，导致即使计算逻辑正确，也无法通过评测。
核心业务逻辑存在漏洞与格式问题并列的是业务逻辑的不完善。尤其是在飞机配平评估、货舱容量不足处理这些关键场景，我的代码未能正确处理临界情况，例如当飞机重心超出安全范围时，程序未能输出正确的配平结果或错误提示；在货舱容量不足时，也没有正确判断并给出相应反馈，导致相关测试点全部失分。这反映出我对业务规则的理解不够深入，边界条件的考虑不够周全。
输入处理的健壮性不足虽然部分非法输入测试点通过了，但 tc8 这类输入范围非法的测试点仍出现了格式错误，说明我的输入校验逻辑存在遗漏，或是在处理非法输入时，输出的错误信息不符合题目要求的格式规范。

改进建议

1.优先对齐输出格式：将题目中所有输出示例复制下来，逐字核对提示信息、标点符号和小数位数，确保输出与评测系统要求完全一致。
2.完善核心业务逻辑：针对配平评估、货舱容量处理等失分模块，重新梳理业务规则，补充临界值测试用例，确保所有边界场景都能被正确处理。
3.强化输入校验：统一非法输入的处理逻辑，确保所有异常输入都能被捕获，并输出符合格式要求的错误提示信息。

总结

三次题目集的作业实践，是我从“完成功能”到“理解面向对象设计”的完整成长过程，也让我在一次次迭代和踩坑中，对代码质量、架构设计和工程实践有了系统性的认知。第一次作业，我以货物与航班实体类为核心，通过封装属性与访问器方法完成基础数据管理，当时仅想着实现功能，直到用 SourceMonitor 度量后才意识到，低圈复杂度和浅代码块深度带来的优势——平均圈复杂度1.30、最大复杂度2、最大代码块深度3的指标，让我第一次体会到“低复杂度”不是抽象概念，而是通过职责拆分、减少嵌套就能实现的、实实在在的可读性与可维护性提升，打破了我此前“能跑就行”的片面认知。第二次作业，随着货舱、位置等实体类和调度、校验工具类的加入，我开始构建“实体类-业务类-工具类”的分层架构，让 Flight、CargoCompartment 专注数据管理，LoadDispatcher 承担调度逻辑，InputValidator 实现输入校验，476行代码规模下仍保持平均圈复杂度1.14、最大圈复杂度3的低复杂度水平，这让我深刻理解了“高内聚、低耦合”的核心价值：职责清晰的分层不仅让代码结构一目了然，更让后续的调试与扩展变得高效，每一个类只做一件事，既避免了逻辑混乱，也降低了维护成本。到了第三次作业，乘客、行李与飞机重心计算等复杂业务模块的加入，让架构进一步扩展，而评测系统的结果则给了我最直接的反馈——50/100的得分让我清晰看到，此前被忽视的细节恰恰是工程实践的关键：输出格式的严谨性、边界条件的全面覆盖、业务规则的精准实现，哪怕逻辑计算正确，格式不符、临界场景处理不当都会导致评测失败，尤其是配平评估、货舱容量不足等核心业务场景的失分，让我意识到面向对象设计不仅是类的划分，更要为复杂业务规则和边界场景提供可靠的实现保障。这三次作业下来，我不再把面向对象看作“写几个类”的形式化流程，而是真正理解了它作为工具的意义：通过封装、职责拆分与低复杂度控制，让代码既能高效实现业务需求，又能保持良好的可读性、可维护性与可扩展性，而评测中的踩坑经历，更让我明白严谨性和细节把控在工程实践中的重要性，这些经验都为后续更复杂的开发任务打下了坚实基础。