面向对象——前三次PTA作业集总结

前言

本阶段共完成了三个题目集，分别是航空器配载与货运管理系统1、2、3；即是对航空器配载与货运管理系统进行了初始设计，并且随着学习知识点增多、要求增多而进行了循序渐进的改进、优化。
三次作业各有异同，分别以不同形式展开，以下是三次作业集的知识点、题量、难度等情况。

航空器配载与货运管理系统	知识点及分析	题量	难度
一代	基础类设计（类的封装、构造方法等）、数组操作、排序算法的简单实现	要求较少，题量代码约100行	低
二代	集合框架、列表操作、业务逻辑分离、ArrayList集合框架，多种判断逻辑共同实现	要求适中，题量代码约200行	中
三代	多模块协作、数据校验、重心计算。处理旅客行李、前后货舱、重心计算等更复杂的业务场景	要求较多，题量代码约300行	中上

本文将结合三次作业源代码、类图结构、MetricsReloaded、代码运行测试情况对三次作业分别进行系统性总结，分析复杂度循序渐进的变化、代码设计、踩坑心得、学习收获等。

设计与分析

第一次作业

第一次作业共包含五个类：Cargo货物类、Flight航班类、CargoSorter排序工具类、LoadManifest装载清单类、Main主类。本次作业采用数组作为存储容器，结构简单直白。其中Cargo类与Flight类为实体类，仅用于存储属性并提供getter方法；LoadManifest负责货物装载、重量统计、超载判断；CargoSorter专门提供排序方法，实现货物重量降序选择排序。

 

本次作业严格遵循基础封装原则，所有成员变量私有化，对外提供访问方法，符合面向对象封装特性。主方法负责数据输入、对象创建、流程调用，程序执行流程线性清晰。

类图

依赖关系：本次作业类之间依赖关系简单，Main类依赖Flight、LoadManifest、CargoSorter；LoadManifest依赖Cargo和Flight；CargoSorter无任何依赖，属于独立工具类。

复杂度分析（使用MetricsReloaded）

可以看到，绝大多数方法：v(G)（圈复杂度） = 1

而CargoSorter.sort(Cargo[], int)：v(G) = 4（全文件最复杂的方法排序方法里有 3 个分支 / 循环）但v(G)仍<10的安全阀值(PS.作业要求的是选择排序，复杂度高不可避免)。
总的来说，整体复杂度极低，方法职责高度单一，结构化程度很高(所有方法的 iv(G) ≤ 3)

小结（一）

第一次作业是典型的入门级面向对象练习，代码简单，通俗易懂。本题让初学的我理解了各个类之间的关系与职责的精细划分，让我学会了类的设计，整体而言收获许多，初次设计让我脑海里真正有了面向对象设计程序的框架，也让我对本系统后面的改进更加方便，更加快速，更加舒服。

(PS.由于先前有过C语言经验，各类算法对我而言不是问题)

第二次作业

第二次作业在第一次基础上新增Position位置类（无论是在第二次还是第三次作业中，这个东西仿佛只是走个过场。。全程只有输入端有他😂）、CargoCompartment货舱类、LoadDispatcher调度类、InputValidator输入校验类。

存储结构由数组改为了ArrayList动态集合，支持动态扩容，解决第一次数组定长缺陷，发挥了ArrayList很大优势。

航班不再直接装载货物，而是管理多个货舱，每个货舱独立限制载重，业务层级更加清晰。

本次作业职责划分更加专业化：实体类包含Cargo、Flight、Position、CargoCompartment；工具类包含LoadDispatcher、InputValidator；Main类仅负责输入、调度、输出。

类图

依赖关系：Main 类依赖 Flight、CargoCompartment、LoadDispatcher、InputValidator；Flight 依赖 CargoCompartment；CargoCompartment 依赖 Position、Cargo；LoadDispatcher 依赖 Cargo、CargoCompartment；InputValidator 无任何依赖，属于独立工具类。

复杂度分析

第二次作业代码量大幅增加，方法数量大幅提升。LoadDispatcher.sortCargos()使用了冒泡排序，v(G) = 4,仍不变。

其余方法复杂度基本维持在1~3之间，整体代码质量依旧良好。

本次新增输入校验工具类，大量使用静态方法，减少代码冗余。集合遍历代替数组下标访问，代码可读性提升。但存在部分方法过长、重复遍历集合的问题，例如多次遍历集合计算重量，造成性能浪费。

 

小结（二）

第二次作业让我体会到面向对象优化迭代的过程。从固定数组转为集合、从单货舱转为多货舱、从简单业务转为分层调度，代码工程化程度显著提高。我深刻认识到工具类的重要性，将通用查找、排序、校验方法抽离，能够极大提高代码复用率。同时也发现自己代码存在重复遍历、没有缓存计算结果的缺点。

第三次作业：

第三次作业为航空载重平衡专业模拟系统，在前两次货物、货舱、航班基础上新增旅客、行李、力矩、重心计算模块。新增Passenger旅客类、Luggage行李类、WeightBalanceCalculator载重计算工具类。本次代码分工达到最完善，实体类、工具类、计算类、校验类完全分离。

本次作业引入异常捕获机制，Main方法全部代码放入try-catch代码块，输入不合法时主动抛出异常并终止程序。载重平衡计算器全部使用静态常量，模拟真实飞机空机重量、力臂、平均气动弦长，通过物理公式计算飞机重心百分比，判断飞行是否安全。

本次作业严格划分类的职能：实体类包含Cargo、Flight、Position、CargoCompartment、Passenger、Luggage；工具类包含LoadDispatcher、InputValidator、WeightBalanceCalculator；Main类仅负责输入、调度、输出。

类图

 

依赖关系：Main类依赖Flight、CargoCompartment、Passenger、LoadDispatcher、InputValidator、WeightBalanceCalculator；Flight依赖CargoCompartment、Passenger；CargoCompartment依赖Position、Cargo；Passenger依赖Luggage；LoadDispatcher依赖Cargo；InputValidator无任何依赖，属于独立工具类；WeightBalanceCalculator仅依赖Flight完成载重平衡计算。

复杂度分析

第三次作业代码体量为三次作业中最大，业务逻辑最为繁琐，不再以排序循环作为主要复杂点，而是综合输入校验、异常捕获、集合遍历、数学公式判断、多分支状态判定为一体。其中圈复杂度最高的方法为Main主方法，圈复杂度达到11，为本项目复杂度最高方法。原因是主方法内部存在多处连续判断、双层货物录入循环、超载if判定、多重输出分支、异常捕获结构，导致判定路径大幅增多。其余实体类方法、获取方法、计算工具类方法圈复杂度普遍为1，均为顺序执行代码，不存在判断、循环等复杂逻辑。

小结（三）

本次代码依旧存在重复遍历集合的问题，例如多次遍历旅客集合、货舱集合用于重量累加计算，虽然不影响本次作业运行，但是造成了不必要的性能开销。相较于前两次作业，第三次代码规范性最好，工具类拆分明确、常量统一管理、输入校验完善，同时加入try-catch异常处理机制，提高了程序健壮性。

第三次作业让我真正理解面向对象在专业行业软件中的应用。飞机重心、力矩、载重限制都是真实航空专业知识，代码不再是简单模拟业务，而是具备实际工程意义。同时我学会异常处理、静态常量设计、数学公式代码化，理解复杂业务必须拆分工具类进行计算，避免主方法臃肿。

 

采坑心得

第一次作业踩坑记录

在未修正的原始代码中，我使用了 nextLine()nextDouble() 、nextDouble()  、nextInt() 混合输入的方式：

String flightNo = sc.nextLine();
double maxWeight = sc.nextDouble();
int n = sc.nextInt();
sc.nextLine();

在货物录入循环中，又加入了条件判断的换行处理：

if(i<n-1) sc.nextLine();

这种写法会导致输入流读取错乱。当输入数据格式严格、无多余换行时，程序会出现读取不到数据、跳过输入、数组越界等问题，最终触发非零返回。

第二次作业踩坑记录

 一、排序后使用 indexOf 导致货舱匹配错误

在未修正的原始代码中，我先对货物集合进行排序，再通过 indexOf 获取原始下标：

int index = cargos.indexOf(cargo);
String targetId = targetCompIds.get(index);

这一写法存在严重逻辑错误。排序后的货物顺序已经改变，indexOf 获取到的下标不再是原始输入顺序的下标，导致货物与目标货舱完全不匹配，出现货物装错舱位的问题。

二、输出格式多余文字导致判题错误

System.out.printf("货物[%s 重量:%.1fkg] → 装入货舱[%s] 失败 (超载)\n");

 原题输出格式表述：装载失败：货物[名称 重量:重量值kg] → 装入货舱[货舱ID] 失败 (超载)。非得把(超载)删掉才给过，何意味，这个坑谁都得踩一脚😠！并不是自身问题。

第三次作业踩坑记录

 一、输入范围校验错误，导致合法数据被误判拦截

throw new IllegalArgumentException("输入必须在 " + 1 + " 到 " + high + " 之间！");

依旧何意味，本应该是最小到最大之间，题目也没有给失败的案例，只能自己猜哪里有问题，搞心态，搞红温😡。

二、输出格式多余文字导致判题错误

System.out.printf("!!! 警告：[1]剩余容量不足(当前载重%.1fkg/最大载重量%.1fkg)，请重新分配或减轻重量！\n");

 首先，当前载重后面的kg不要，最大载重量这几个字不要，没有读懂题目给的输出格式，算是我自己的问题。

三、LoadDispatcher 排序逻辑错误且完全未使用

if (list.get(j).getId() > list.get(j + 1).getId())

Main函数中我使用的是增强for循环，没意识到这个排序根本没有用到，按理来说题目没有给明确要求，那么我就按装载顺序输出了，这个排序循环相当于是冗余了。

踩坑小结

踩坑挺多的，也不止列出来的这么多，代码仍有瑕疵，除了第一次一些nextline()的使用外，基本上是逻辑与格式的错误。在学习了Integer等类，parseInt等方法后基本没有输入方面的问题。
踩坑感觉是很正常的，极少情况下代码是一次写对的，难免有bug要修改，难免有逻辑要优化，在三次作业中循序渐进地去完善这个系统，我认为是编写这个系统的正确方式，要慢慢来，一次性不要想太多方面，要严谨的来，按计划得来，出错不要紧，要有一个纠错的心态，踩完坑爬上来，自己的收获会是巨大的。

改进建议

代码结构改进

三份代码中Main主方法普遍偏长，特别是第三次main方法代码行数超过120行，不符合单一职责原则。可以将输入模块、打印模块、计算模块拆分至独立工具类，减少主方法臃肿程度。
第一次、第二次排序方法为手写简单排序，算法效率低，数据量大时排序速度慢。可以使用JDK自带工具类Collections.sort结合比较器完成排序，减少手写循环出错概率，降低圈复杂度。（但是题目要求不让用😖）

健壮性改进

目前代码仅对输入数值做非负判断，未对空字符串、特殊字符、null值进行校验。后期可以增加字符串校验、对象非空判断，防止空指针异常。浮点数可以比较统一采用误差范围判断，杜绝精度丢失问题。

扩展性改进

第三次作业重心范围硬编码写在代码中，应当提取为静态常量，便于后期修改。飞机空机重量、力臂、货舱力臂全部常量化，提高代码可维护性。未来若新增货舱、新增机型，仅需修改常量无需改动业务逻辑。（其实写代码的时候省懒了）

总结

经过三次航空货物配载系列作业的递进式训练，我系统且完整地掌握了Java面向对象编程的核心思想，重点吃透封装特性，同时理解了继承、多态的适用场景。三次作业依托同一航空业务不断迭代，我清晰体验了软件开发迭代流程：从最简单的单一数据存储，逐步升级为分层架构、工具拆分、异常处理、专业公式计算的完整工程代码。在类的设计方面，我熟练掌握实体类、工具类、业务控制类的划分标准，明白实体类只负责存储数据、工具类负责通用算法与校验、主类仅负责流程调度的开发规范。同时，我完成了从基础数组到动态集合的技术过渡，深刻理解ArrayList动态扩容、集合遍历、引用传递等底层特性，编码思维由单纯实现语法逻辑转变为面向业务、面向结构、面向质量的编程思维。

 

此外第三次作业结合航空专业知识，让我明白编程语言可以服务专业领域，代码不仅是语法练习，更是解决实际工程问题的工具。力矩、重心、载重平衡让我体会到代码与数学、物理、专业知识结合的强大能力。

 

三次循序渐进的航空货物配载作业，是我从基础语法走向面向对象思想的重要转折点。从最初只会简单编写顺序代码，到能够独立划分类结构、设计依赖关系、拆分业务模块、分析代码质量，我的编程思维完成了质的提升。虽然目前代码仍存在注释缺失、优化不足、边界考虑不全等问题，但整体编码逻辑、规范程度、调试能力都在持续进步。在今后的Java学习中，我将严格遵守编码规范，养成写注释、合理命名、精简方法、减少冗余的良好习惯。同时主动预判边界条件、强化异常处理、优化代码结构，不断降低代码耦合度与复杂度。我将以本次三次作业为基础，深耕面向对象思想，不断积累项目经验，为后续复杂程序开发、团队协作开发打下扎实、稳固的编程基础。

教师、课程、作业、实验、课上及课下组织方式等方面做的非常好，教师有问必答，群里回复及时，作业很有创新，三次作业循序渐进，业务连贯，非常适合入门者学习，实验非常有实验精神，课上老师讲课激情，也会进行bug调试，排查流程，修改思路，带写代码，课下与同学们打成一片。
建议后期作业继续沿用同一业务场景迭代升级，让学生体会软件迭代开发流程。建议课堂增加代码度量、代码优化、类图绘制教学，让学生不仅会写代码，更会分析代码质量。