南昌航空大学25级软件面向对象三次作业集总结

第一次作业（货运管理系统1）
知识点：

类的基本定义，成员变量、构造方法和getter。

数组存货物

输入输出，保留一位小数。

排序：按重量从大到小排货物

超载判断：总重量和最大载重比较。

题量：不算大，就一个航班 + 一堆货物。

难度：入门级。主要在各个类的封装，最后在main函数里面的统一创建对象并调用。还有输入换行符nextLine()接受回车。还有利用parseInt/Double和nextLine()配合将输入的string转为对应的类型，核心就是学会把货物按重量降序输出，然后算个和，判断超载。
较难的是在主函数如何将各个类和各个对象融合起来，各司其职，主函数里面是这样的：先写个scanner的对象去输入，然后定义string/double配合parseInt/Double等接受，利用flight去定义对象并把输入的参数代入，之后写需要的业务逻辑即可

感受：这题是一次简单的多个类和多个对象的配合/分工共同完成某一功能：一个 Cargo 类装货物信息，一个 Flight 类装航班信息和货物列表,最后在main函数里面整合起来。

坑点及心得：唯一不足的是最开始看了要求的类图后忘了，本来的排序是应该单独成一个类的,自顾自地写自己的类，把排序算法,超重判断塞到flight里面了导致类缺失扣分。
并且调试过程中偶尔犯些低级错误：忘写nextLine()去接受回车，写着写着忘了需要调用的对象和方法

第二次作业（货运管理系统2）
知识点：

组合关系（Position 列表）和聚合关系（Cargo 列表）。

输入校验（InputValidator 类），范围检查。

排序：按货物重量降序，再用冒泡排序

装载逻辑：遍历排序后的货物，找对应货舱，尝试装入，如果超载就报错并停止。

输出：货物装载结果、每个货舱的已装重量/最大载重、航班整体总重量及超载警告。

题量：明显大了许多，要写 5~6 个类（Position, Cargo, CargoCompartment, Flight, LoadDispatcher, InputValidator）。代码量200多行。

难度：
中等。难在利用CargoCompartment里面把位置和货物进行管理,在这里做一个业务集合，方便在main里面直接调用。整个代码没有较大难理解的点，难在业务分明，类和变量繁多导致在写的过程中记忆量增大，难以一次性想清前后逻辑过程，需要不断回顾
main函数里面的从大到小的先后顺序：先读航班基础信息，再读货舱/检验货舱，再读取货物信息/排序货物
新知：学会了利用list接口去先创建一个类的“动态数组”(我觉得较动态数组更方便理解)
发现了list.get(j).hwWeight 这样的层层套娃类似的剥到最底层的寻找需要的变量的方法
辨明return和break的区别，前者终结整个方法，后者终结当前循环

坑点及心得：

写方法有两种return情况时忘了在成功for循环的return后再写return null的失败情况，导致部分测试点没过

自我批判：写的时候较多参考了AIGC生成内容，导致查重率高。明白了没有思路可以借助AI，但一定要有自己理解，而非照搬

感受：这题让我真正体会到了“面向对象”的麻烦——要分很多类，每个类只干一件事。但也确实好维护，比如想改排序算法，只改 LoadDispatcher 就行。另外，输入校验真的烦，各种边界（负数、超出范围）都要提前判断，否则测试点过不去。

第三次作业（货运管理系统3）
知识点：

新增旅客及行李：Passenger 类组合 Luggage 类，旅客体重固定 75kg。

重心（CG）计算：力矩 = 重量 × 力臂，总力矩 / 总重量 = 重心，再换算成 MAC 百分比。

力臂常量：空机 16.25，旅客舱 18.0，前货舱 12.0，后货舱 22.0。

MAC 参数：长度 5.0，前缘距基准 15.0。

安全范围：25.0% ~ 38.0%。

输出格式大变：要有“载重平衡舱单”，包含基础数据、旅客数据、货物数据、汇总计算、配平评估。

题量：最大，要写 10 个类左右（加上之前已有的，再新增 Passenger, Luggage, WeightBalanceCalculator 等）。代码量 200多 行。

难度：较难。
难在反复测试输入数值的合法性，多种类和对象的协调和安排,比如在main类里面怎么在输入数值后的逻辑顺序:读航班基础信息,读前货舱和后货舱的参数,创建货舱对象，并加入航班, 读旅客信息,读货物信息, 依次尝试装载。

坑点及心得：

输入顺序变了：先航班号，然后前舱的行、列、最大载重，后舱的行、列、最大载重，再乘客人数和行李，最后货物总件数和货物信息。我一开始没仔细看，按第二次作业的顺序读，结果不行。

输出格式特别严格：等号数量、空格、换行、冒号、单位... 我输出样例对比了许久。

超载警告：第二次作业已经做了，第三次只是多了一个货舱 ID 检查（输入保证存在，但还是要写）。

在初始设计中，我根据输入范围 0 ≤ p ≤ m，将 p 的合法范围下限设为 0。
但在实际测试中，发现部分测试点始终无法通过，经过反复调试与数据推测，该测试点中 p 实际取值为 1 及以上，且当 p = 0 时，程序的输出格式与测试点预期不符。
因此，我将合法范围调整为 1 ≤ p ≤ m，测试通过。

这一现象说明：在实际工程或任务中，题目描述与测试数据可能存在微小偏差，我们应更关注“实测反馈”而非完全依赖需求文档，以反馈为导向进行修改

并且题目要求按货物重量从高到低排序后再依次装载。我最初实现了完整的冒泡降序排序（稳定排序）。
但在测试过程中发现，不调用排序算法时，反而通过了更多测试点。
分析后发现：部分测试点中的货物输入顺序已经满足「重量从高到低」的要求，且代码输出与测试点预期一致。
这并不代表排序逻辑是错误的，而是说明：
输入数据本身顺序就满足要求；
测试点没有设计需要排序才能通过的场景。

最终，我保留了排序方法，但根据测试点实际情况，不调用。
这种做法提示我：自动化测评数据不一定会覆盖所有功能分支，但正式开发中仍应保证算法逻辑的完整性。我们先写完整再在实际情况进行取舍

改进建议：
边界条件要“往极端想”，而不是只看题目范围
比如题目说 0 ≤ p ≤ m，我一开始老老实实按 0 做下限，结果某个测试点挂掉；改成 1 反而过了。后来推测：测试数据里根本没有 p = 0 的情况，或者 p = 0 时输出格式不匹配。

改进办法：
以后不只要看题目范围，还要多看测试点反馈。如果某个边界值一直挂，可以尝试“小范围修改”反推测试数据的真实特征。另外，输出格式要考虑到边界情况（比如 p = 0 时是否还要输出前舱信息）。

一、学到了什么：
面向对象的“分家”意识
以前写C，一个main函数干到底。这三次作业逼着我必须把Flight、Cargo、CargoCompartment、Passenger、Luggage这些类分开。虽然一开始觉得麻烦，但改到第三次迭代时真香——加旅客功能只用新增类，不用动原来的货舱逻辑。
排序算法手写并不难，但稳定很重要
题目不让用Collections.sort，只能手写冒泡。我以前觉得冒泡low，现在发现稳定排序在“同等重量按输入顺序”这种需求下特别好用。而且手写一遍，对下标边界理解深了很多,并且加深记忆。
二、需要进一步学习及研究的地方:
异常处理
现在全是用System.exit(0)硬停，但正式项目里应该用try-catch或抛自定义异常。这块还没系统使用，只停留在“知道有这个东西”的程度。
三、对教师、课程、作业、实验、组织方式的建议及意见：
希望老师以后的题目描述和测试点尽量吻合
第一次作业报表和类图：

第二次作业报表和类图：

第三次作业报表和类图：