当前位置：首页 > news >正文

飞机载重平衡与货物管理系统三次作业集总结

news 2026/6/10 19:30:03

前言
这学期的三次迭代作业，我都在做飞机载重平衡与货物管理系统。从第一次只会写简单类，到第三次能算重心、做平衡，我真的学到了很多。不光是 Java 语法和面向对象设计，更重要的是把代码、算法和航空常识结合起来，实际动手能力提升特别明显。

作业集概述
下面是三次作业的关键数据对比，能很直观看到难度一步步往上走：第一次只是基础功能，第二次加了多舱和坐标，第三次直接上重心计算，代码量和复杂度都涨了不少。

作业集	代码行数	类数量	方法总数	最大复杂度	主要知识点
作业集1	196行	6个	29个	4	面向对象基础、数组操作、选择排序
作业集2	406行	7个	44个	6	多舱位管理、位置坐标、装载调度
作业集3	454行	11个	56个	4	重量平衡计算、旅客行李管理、重心分析

从代码质量分析数据可以看出，作业集的复杂度呈现规律性递增：

代码规模增长：作业集1到作业集2增长约107%，作业集2到作业集3增长约12%。这表明前两次作业是功能的快速扩展阶段，第三次作业则是在已有基础上进行深度优化和功能完善。

复杂度控制：三次作业的平均复杂度分别为1.25、1.53和1.27。值得注意的是，作业集3虽然功能最复杂，但平均复杂度反而有所下降，说明我在代码设计上逐渐掌握了更好的模块化拆分方法。

设计与分析

作业集1：基础架构搭建

代码质量分析

根据SourceMonitor报告，作业集1的关键指标如下：

代码行数：196行
语句数：117条
类与接口数：6个
平均方法数/类：4.83个
平均语句数/方法：2.45条
最大复杂度：4（CargoSorter.Sort方法）
最深嵌套块：5层

类图分析

作业集1采用了简单的分层架构设计：

核心类职责划分：

Main类：程序入口，负责协调各组件
Cargo类：货物数据模型，封装重量和名称属性
Flight类：航班数据模型，管理航班号、最大载重和货物列表
LoadMainfest类：装载清单管理，负责货物的添加和排序
CargoSorter类：货物排序器，实现选择排序算法
OI类：输入输出操作类，负责数据的读取和结果展示

设计特点：

第一次作业其实就是搭基础架子。当时刚学面向对象，思路很简单：用 Main 当入口，Cargo 存货物信息，Flight 管航班数据。虽然类分得不算完美，但每个类都有自己的活，算是第一次真正用类和对象写完整程序。

核心算法分析

选择排序实现：

CargoSorter类实现了选择排序算法，时间复杂度为O(n²)。该算法通过每次从未排序部分选择最大元素放到已排序部分的末尾。虽然效率不是最优，但对于小规模数据足够使用。

数据存储方式：

采用固定长度数组存储货物，需要手动实现动态扩容逻辑。这种方式虽然直观，但在数据量较大时效率较低。

作业集2：功能扩展与优化

代码质量分析

作业集2的关键指标如下：

代码行数：406行（较作业集1增长107%）
语句数：168条（增长43.6%）
类与接口数：7个（新增1个）
平均方法数/类：6.20个（增长28.2%）
平均语句数/方法：3.87条（增长57.6%）
最大复杂度：6（OI.outputtheLoad方法）
最深嵌套块：5层

类图分析

作业集2在作业集1的基础上进行了显著扩展：

新增类：

Position类：引入位置坐标概念，支持货物与舱位的精确匹配
CargoComparator类：替代LoadMainfest，专门负责舱位管理
LoadDispatcher类：装载调度器，负责装载逻辑的协调
InputValidator类：输入验证工具类

职责重构：

将排序职责从LoadMainfest分离到LoadDispatcher
将验证职责独立为InputValidator类
Flight类扩展为支持多个舱位的管理

类间关系：

Main类作为协调中心，使用OI类进行输入输出，使用LoadDispatcher进行装载调度。Flight类包含多个CargoComparator（舱位），每个舱位包含多个Cargo（货物），并关联到具体的Position（位置）。

架构改进分析

单一职责原则的应用：

作业集2明显体现了单一职责原则的应用。LoadMainfest类的职责被拆分到多个类中：

CargoComparator负责舱位的货物管理
LoadDispatcher负责装载调度和排序
InputValidator负责输入验证

这种职责分离使得代码更易于维护和扩展。

数据结构优化：

引入ArrayList替代固定数组，简化了动态扩容逻辑。CargoComparator类使用ArrayList存储货物，相比作业集1的数组实现更加灵活。

作业集3：系统综合化与专业化

代码质量分析

作业集3的关键指标如下：

代码行数：454行（较作业集2增长12%）
语句数：280条（增长66.7%）
类与接口数：11个（新增4个）
平均方法数/类：5.09个（减少18%）
平均语句数/方法：2.54条（减少34.4%）
最大复杂度：4（InputValidator.readInt方法）
最深嵌套块：5层

类图分析

新增功能分析

旅客与行李管理：

新增Passenger类和Luggage类，实现了旅客及其行李的管理。Passenger类包含标准体重（75kg）和行李重量，能够计算旅客的总重量。

重量平衡计算：

新增WeightBalanceCalculator类是本次作业的核心。该类实现了航空领域的重量平衡计算：

空机重量：40000kg
空机力臂：16.25m
旅客力臂：18.0m
前舱力臂：12.0m
后舱力臂：22.0m
重心安全范围：25%-38% MAC

计算流程：

计算旅客总重量和力矩
计算货物总重量和力矩（分前舱后舱）
汇总计算起飞总重量和总力矩
计算实际重心位置
评估重心是否在安全范围内

代码质量提升：

虽然功能复杂度增加，但平均复杂度从1.53下降到1.27，说明代码结构更加清晰。方法拆分更加合理，每个方法的职责更加明确。

采坑心得

数组操作问题

动态扩容陷阱

问题描述：

在作业集1和作业集2中，使用数组存储货物时需要手动实现动态扩容逻辑。这个过程容易出现错误：

public void addCargo(Cargo cargo1) {if (cargo1 == null) {return;}Cargo[] newCargos = new Cargo[cargos.length + 1];for (int i = 0; i < cargos.length; i++) {newCargos[i] = cargos[i];}newCargos[cargos.length] = cargo1;this.cargos = newCargos;
}

问题分析：

手动扩容存在以下风险：

性能问题：每次添加元素都需要创建新数组并复制，时间复杂度为O(n)
空指针风险：如果源数组为null或元素为null，可能导致异常
代码冗余：每个需要动态扩容的类都要重复这段代码

解决方案：

作业集3中采用ArrayList替代数组，代码简化为：

public void addCargo(Cargo cargo1) {if (cargo1 == null) return;cargos.add(cargo1);
}

数组越界异常

问题描述：

在访问数组元素时，如果没有正确处理边界条件，容易引发ArrayIndexOutOfBoundsException。

问题分析：

在作业集1的OI.getthecargos方法中，创建数组时使用了固定长度：

public Cargo[] getthecargos(Cargo[] cargos, int num){Cargo[] c = new Cargo[num];for (int i = 0; i < num; i++) {// ...}return c;
}

如果num参数不正确或输入数据不足，可能导致数组越界。

排序算法问题

选择排序与冒泡排序的混淆

问题描述：

在作业集1和作业集2中使用选择排序，而作业集3误写为冒泡排序：

// 作业集1的选择排序
public Cargo[] Sort(Cargo[] cargo) {int len = cargo.length;for (int i = 0; i < len - 1; i++) {int maxIndex = i;for (int j = i + 1; j < len; j++) {if (cargo[j].getWeight() > cargo[maxIndex].getWeight()) {maxIndex = j;}}Cargo temp = cargo[i];cargo[i] = cargo[maxIndex];cargo[maxIndex] = temp;}return cargo;
}// 作业集3的冒泡排序
public Cargo[] Sort(Cargo[] cargo) {int len = cargo.length;for (int i = 0; i < len - 1; i++) {for (int j = i + 1; j < len; j++) {if (cargo[i].getWeight() > cargo[j].getWeight()) {Cargo c = cargo[i];cargo[i] = cargo[j];cargo[j] = c;}}}return cargo;
}

问题分析：

两种排序算法虽然都能实现排序功能，但效率不同：

选择排序：每次外层循环只进行一次交换，共n-1次交换
冒泡排序：每次比较都可能交换，最多n(n-1)/2次交换

影响评估：

在数据量较小时，两种算法差异不明显。但在大数据量情况下，选择排序更优。

输入验证问题

缺乏验证导致异常

问题描述：

作业集1中直接解析输入而不进行验证：

double max = Double.parseDouble(sc.nextLine().trim());
int num = Integer.parseInt(sc.nextLine().trim());

如果输入格式不正确或超出合理范围，会抛出NumberFormatException。

解决方案：

作业集2和作业集3引入了InputValidator类，提供了完整的输入验证机制：

public static int readInt(Scanner sc, int min, int max, String errorMsg) {String line = sc.nextLine().trim();int value;try {value = Integer.parseInt(line);} catch (NumberFormatException e) {System.out.println(errorMsg);System.exit(0);return 0;}if (value < min || value > max) {System.out.println(errorMsg);System.exit(0);}return value;
}

类设计问题

职责划分不清晰

问题描述：

作业集1的LoadMainfest类承担了过多职责：

货物集合管理
货物排序调用
总重量计算

问题分析：

违反了单一职责原则，导致类的复杂度较高，不利于维护和测试。

解决方案：

作业集2进行了职责拆分：

CargoComparator：舱位货物管理
LoadDispatcher：装载调度和排序
InputValidator：输入验证

测试结果分析

测试用例设计

针对三次作业，我设计了以下测试场景：

测试场景	输入条件	预期结果	实际结果
正常装载	货物重量小于舱位容量	装载成功	通过
超载检测	货物重量超过舱位容量	装载失败并提示	通过
空输入	输入为空或格式错误	提示错误并退出	通过（作业集2、3）
边界值测试	货物重量等于舱位容量	装载成功	通过
重心计算	旅客和货物分布合理	重心在安全范围	通过（作业集3）