南昌航空大学软院前三次PTA作业集总结blog

📅 2026/7/3 14:18:56 👁️ 阅读次数 📝 编程学习
南昌航空大学软院前三次PTA作业集总结blog

前言

通过这三次迭代的航空货运系统作业,我完整地经历了一个软件从简单功能到复杂业务逻辑的演进过程。这个过程不仅强化了Java基础语法,更让我深刻体会到:

  • 面向对象设计:如何将现实世界(货物、航班、旅客、货舱)抽象为系统中的对象。

  • 代码可拓展性:为应对每次新增的需求(从货物到旅客,再到平衡计算),如何设计易于扩展的系统架构。

  • 复杂业务处理:如何处理核心算法(如重心计算、重量排序)并整合多个模块。

测试的重要性:从手动测试到思考边界条件,认识到构建有效测试用例的必要性。

第一次作业:基础货物装载系统

作业需求

实现一个基本的货物配载系统,核心功能:

  • 管理航班和多个货舱。

  • 按重量降序处理货物,并尝试装入指定货舱。

  • 检查各货舱及整体是否超载。

代码结构与分析

    • 代码规模:约150行,包含FlightCargoCompartmentCargoLoadDispatcherMain等类。

    • 类图

main

    • Flight: 聚合了货舱列表,作为系统核心。

    • CargoCompartment: 管理货物和载重。

    • LoadDispatcher: 承担了排序查找两个职责,初步实现了控制逻辑与数据分离。

复杂度分析

第一次作业的复杂度分析如下:

方法 v(G) 问题说明
Main main 8 包含了输入、装载、输出所有逻辑,循环嵌套条件判断
LoadDispatcher sortCargos 5 选择排序的双层循环
Flight findCompartment 4 线性遍历查找货舱

可以看出Main.main方法的复杂度最高,因为这个方法承担了过多职责:读取航班信息、读取货舱信息、读取货物信息、排序、装载输出、状态判断全部挤在一起。后续作业需要将其拆分为多个独立方法。

用例测试

屏幕截图 2026-05-17 115927

第二次作业:引入旅客管理

作业要求

在第一次作业基础上增加:

  • 旅客及其行李管理(旅客标准重量75kg + 行李重量)

  • 前后货舱区分(前舱1号、后舱2号)

  • 货物分配策略(前p件货物装前舱,其余装后舱)

  • 细分超载类型(超过最大起飞重量、超过最大业载重量)

实现方法

新增PassengerLuggage类,Flight类增加旅客列表管理。LoadDispatcher的排序算法改为冒泡排序。货物分配策略直接在Main中通过循环控制实现。

代码规模

第二次作业代码规模约250行,新增2个类。

类图

PTA2

  • Passenger:旅客类,包含行李对象

  • Luggage:行李类

  • InputValidator:输入验证工具类

复杂度分析

第二次作业的复杂度分析如下:

 
 
方法 v(G) 问题说明
Main main 12 复杂度进一步增加,加入了货物分配策略和超载类型判断
Flight getPassengerTotalWeight 3 遍历旅客列表求和
LoadDispatcher sortCargos 5 冒泡排序实现

Main.main方法的v(G)从8增加到12,主要是因为:

  • 增加了旅客输入循环

  • 增加了货物分配策略(前p件货舱1,其余货舱2)

  • 增加了三个布尔变量的组合判断逻辑

用例测试

屏幕截图 2026-05-17 130929

第三次作业:载重平衡计算

作业要求

在第二次作业基础上增加航空货运最核心的功能:

  • 载重平衡计算(重心CG、重心百分比%MAC)

  • 根据安全范围(25%-38% MAC)给出配平评估

  • 输出完整的载重平衡舱单

实现方法

新增WeightBalanceCalculator类,封装所有平衡计算相关的常量和静态方法。通过calculate方法接收Flight对象,从中提取旅客重量、前后货舱货物重量,按照航空力学公式计算总重、总力矩、重心和%MAC,最后输出格式化的平衡舱单。

代码规模

第三次作业代码规模约350行,新增1个核心类。

类图

PTA3

  • WeightBalanceCalculator:载重平衡计算器,包含所有常量和计算方法

复杂度分析

第三次作业的复杂度分析如下:

 
 
方法 v(G) 问题说明
WeightBalanceCalculator output 8 包含多层嵌套循环和条件判断
WeightBalanceCalculator calculate 5 包含货舱识别和计算公式
Main main 10 相比第二次略有降低(部分逻辑移到计算器)

 

用例测试

屏幕截图 2026-05-17 131023

 

三次作业的演进总结

代码规模变化

作业 类数量 代码行数 核心功能
第一次 5 ~150行 货物装载 + 重量排序
第二次 7 ~250行 +旅客管理 + 货舱区分
第三次 8 ~350行 +载重平衡计算

 

复杂度趋势

类/方法 第一次 第二次 第三次 说明
Main.main v(G)=8 v(G)=12 v(G)=10 第三次部分逻辑移到计算器,略有改善
排序方法 选择排序 冒泡排序 冒泡排序 算法未优化,但业务可接受
货舱识别 字符串ID 字符串ID 始终使用字符串ID,存在扩展性问题
核心计算 新增类 新增独立计算器

 

通过三次迭代作业,我深刻体会到:面向对象设计的核心并非写出能运行的代码,而是通过持续重构将复杂业务逻辑封装为高内聚低耦合的独立模块,从而让系统能够从容地应对需求变化。