航空器配载与货运管理系统blog
前言
知识点：
本次实验设计有关于SPR设计，以及涉及类间关系，如：组合，关联，依赖。有Scanner类的输入，类之间的封装，数据校验，模块化设计。本次OOP作业有一定难度。主要难点在于让各种类满足SPR原则以及如何将代码嵌套率以及提升代码的复用率，个人认为三次迭代作业在于如何提升代码的可维护性，可读性以及模块化，以及开始理解业务之间的关系。
题量：
第一次作业由于第一次被要求做符合SRP之间的设计，所有在构思方面思考过久，大概在一到两天才对SRP原则有一定的初步了解，在设计类方面需思考封装，代码量适中。
第二次作业由于第一次作业有了经验，所以，在类的设计方面比较迅速，并且是对第一次进行迭代所以完成的比较迅速，用一天完成。
第三次作业类原有的基础上加上了乘客，增加了计算了重量，力矩，重心的业务逻辑，由于此次题目判断超载的形式发生了变化，所以对题目的分析多花了点时间，但由于只需要迭代四个类，所以不需要对以前代码做出大的改动，只需要新增加类以及改变主类的输入形式，所以书写方面大约花了两天形式
总结：三次题目是由易到难三次迭代，但因为是迭代式作业，所以需要熟悉SPR原则，对业务要求进行模块化的分解。所以要请清楚老师的要求以及自己的初步构建与题目要求的重合度。题量与代码量相比以前有了显著的提升，所以需要花费比以前更多的时间和精力去完成
设计与分析
第一次作业：
对代码分析结果如下：
解释：
1.通过解释图得知，模块化设计合理，但代码的注释过少，代码的可读性较差。
2.整体复杂度较浅，没有用复杂的if/else语句，但局部嵌套过深，修改时容易出错。
3.最大圈复杂度在7，main方法承担太多逻辑，19条方法调用语句，说明大量方法控制流是扁平的。
类图如下：
心得：优秀代码在于“可读性”与“可维护性”，而不在于能不能跑，小巧扁平且方法复用率高的代码是优秀代码的基础，一个方法只做一件事，一个类只负责一个职责，代码的优化是一个持续的过程，不用追求一步完美，养成写注释的好习惯可以增强代码的可读性。
题目要求：
在航空业中，航班起飞前需要进行严格的“配载”，即计算飞机的旅客、货物、行李的重量分布，计算出飞机的重心位置，以确保飞行安全。本系列作业将围绕这一真实场景展开。
【本次作业需求说明】
设计一个基础的航班货运配载模块。系统需要记录航班的基本信息（航班号、最大起飞重量、最大业载重量）。地勤人员可以按照货物重量从高到低向该航班添加货物（货物名称、重量）。系统需要实时计算当前已装载的总重量，并判断是否超载。
【设计要求】
类设计必须符合单一职责原则（SRP），参考类图如下所示（仅作参考，可自行加工具类）。
注意：类设计如果违背了SRP，此题不得分。
输入格式:
第1行：输入航班号flightNo（字符串，例如CA1201）
第2行：输入该航班最大载重重量maxWeight（实型数，例如1200.0）
第3行：输入该航班要装载的货物件数n（整型数，例如10）
从第4行开始，循环输入要装载的货物的名称cargoName（字符串）和cargoWeight重量（实型数）
提示：在使用Scanner输入的时候，nextLine()方法会接受上一次输入的回车符号，因此，建议大家在nextLine()之前再加一个nextLine()，如下代码所示：
输出格式:
前n行按照装载顺序依次输出货物的信息，格式如下：货物[名称 重量:重量值kg]
第n+1行输出装载的总重量以及该航班最大载重量，格式如下：总重量: 重量值kg / 最大载重: 载重值kg
最后一行输出配载状态，如果没有超载，则输出配载状态：正常，如果超载则输出警告：严重超载
注意：输出的数值均保留1位小数。
设计过程：设计Flight，Cargo，CargoSorter，LoadManifest四个类，Flight与LoadManifest是关联关系，LoadManifest依赖CargoSorter,聚合Cargo，所以在前期构思中，Flight中只有LoadManifest类，Cargo则是用数组的方式定义在LoadManifest，Cargo只负责储存货物的重量以及名字，CargoSorter只负责排序功能，LoadManifest则负责调用CargoSorter,给自己则Cargo数组排序，则Flight应有创造LoadManifest功能，以及自身的基础数据，LoadManifest应有增加Cargo功能，因为LoadManifest中有所有的Cargo的信息，所以获得Cargo总重应该在Loadimanfest中，再有Flight获得与自身最大重量对比，判断是否超载。
踩坑及解决过程：
开始时，超载与排序方面测试点未过，以及在输入数据出现非零返回的情况，由于是在Loadifest类中变加入变排序所以与真实测试的有误差，非零返回情况在于本人一开始是在idea上测试的代码，而PTA平台如果在货物数量为零的情况下，代码会接着往下读取输入，所以在这点上会产生误差，在n==0上加上单独的判断解决非零返回问题，在超载方面，本人想过两种情况，一种是超载了也不会停止继续装货，另一种是超载了立即停止，所以两种都尝试了一遍，最后确定是第一种，而在排序方面是本题最精彩的测试点，在货物重量相同，名字不同的情况下，冒泡排序与选择排序会出现不同的结果，本人在连续测试了几十次后，最后确定本题使用的选择排序。
总结：
细节决定成败：边界条件（如 n=0）、特殊场景必须优先考虑，是程序正常运行的基础，需求至上，编程逻辑要严格贴合题目要求，杜绝主观臆断，精准理解规则才能少走弯路，算法重细节，不同算法在特殊场景下差异显著，要理解原理而非只记实现，耐心测试是解决问题的关键，调试是核心能力，报错和测试失败是成长的契机，学会排查、总结，才能不断提升编程水平。
改进建议：
在数组方面可以换成列表，以及开始增加代码的注释书写习惯，以及开始锻炼模块化的设计思路。
第二次作业
对代码分析结果如下：
解释：
复杂度 18 偏高，而且都集中在 main() 方法里，把大部分逻辑都写在主方法里了，导致主方法变得特别 “臃肿”，每个方法平均只有 3-4 行，说明已经理解了 “单一职责” 的思想，每个方法只做一件小事。且且三分之一都是注释，说明以及对上一次作业有了提升
类图如下：
心得：
本次迭代作业相比第一次增加了前后货仓类，位置类，相当于把之前的LoadManifest变成了数组或者列表，比起上次作业没有太多改动，所以写起来比较容易，但本人烦了一个致命的错误，有一个判断浮点的类，本人看题目没有对于浮点的输入，所以认为没用就没写上去，导致扣分（切记不能主观臆断）。
拓展需求
【本次作业需求说明】
设计一个扩展的航班货运配载模块，实现以下功能：
-
航班信息管理：记录航班号、最大起飞重量、最大业载重量。
-
货舱管理：
每个货舱有唯一标识（如“前舱”）、最大载重、行数、列数（组成位置网格）。
货舱与其位置是组合关系（CargoCompartment 创建时内部生成 Position 列表）。
货舱与装载的货物是聚合关系（Cargo 可独立存在）。
-
货物装载：
输入所有待装载货物（名称、重量、目标货舱ID）。
系统先按货物重量从高到低排序，再依次尝试将货物装入指定的货舱。
如果目标货舱的当前重量 + 该货物重量 ≤ 该货舱最大载重，则装载成功，否则装载失败并给出提示。
-
输出要求：
按排序后的顺序输出每件货物的装载结果（成功或失败）。
输出每个货舱的已装载总重量及状态（是否超载）。
输出航班整体总重量及与最大起飞重量、最大业载重量的对比，判断整体是否超载。
【设计要求】
必须严格遵循单一职责原则（SRP），不得将多个职责合并到一个类中。违背 SRP 本题不得分。
必须实现以下类（参考提供的类图与代码框架）：
Position：表示货舱中的一个位置（行、列），提供 getPosName() 等方法。
Cargo：表示货物，包含 id（货物名称）、weight。
CargoCompartment：货舱类，包含 id、maxWeight、positions（组合）、cargos（聚合），提供 addCargo(Cargo cargo)、getCurrentWeight() 等方法。
Flight：航班类，包含航班号、最大起飞重量、最大业载重量、List。
LoadDispatcher：调度类，负责对货物列表按重量降序排序（sortCargos）、查找货物（FindCargo）。
InputValidator：输入校验类，提供整数、浮点数的范围校验方法。
设计过程：
本次迭代，相比上次只是新加上了几个类，以及改变主类的输入形式，Cargo,Position与CargoCompartment是聚合关系,Position负责存储位置，InputValidator类中均为静态方法判断非法数据，在初始化时Cargopartment先初始化再加入到Flight中，在用一个列表Cargo存储所有的货后，在用排序类进行排序，在再加入到货仓中最后在统一排序，但是，本次代码虽然可以过测试点，但是后期自己使用时出现bug，有一些情况并没有考虑进去，这个有待改进，如主方法的也无逻辑过多，考虑是否给主方法加上输出类
踩坑及解决过程：
本次的超载判断是实时判断，本人还保持第一次的加完后判断，导致测试点未通过，以及在输出方面，在输出格式方面没有及时注意输出超载后面的括号是注释，导致输出格式总是错误的。还有最致命的错误是没有完成要求的所有类，导致扣分。
总结：
这次的航空配载项目，我从类图设计、编码实现到测试通关，踩了不少 “低级但致命” 的坑，也对 “面向对象编程” 和 “项目规范” 有了完全不一样的理解。作为大一学生，这次经历让我明白：代码不仅要 “能跑”，更要 “按要求跑、按规范跑”，细节和结构往往比核心逻辑更决定成败。
第三次作业：
对代码分析结果如下：
解释：
复杂度控制得好，最高复杂度才 3，嵌套深度也很低。10 个类、每个类 5 个方法、每个方法 2-3 行，完美践行了 “单一职责原则”，代码结构清晰。
类图如下：
心得：通过再一次迭代，已经对SRP原则十分清楚，已基本养成注释的习惯，结构划分清楚。
设计过程：
本次迭代，比较第二次判断类进行了更新，新增乘客类，行李类，计算重量类，逻辑为一旦超载或者输入数据不符合要求程序立即停止得出相应输出，同时修改主类的输入形式，主类的输入全由InputValidator完成，同时计算类只负责计算且与Flight为关联关系只需要传入，对相应的货仓前舱后舱货物行李乘客初始化后，对货物的编号进行冒泡排序，再加入到Flight中，先进行超载判断，无超载后再进行后面的输出。
踩坑及解决过程：
首先在强制暂停方面，无法数据非法时做到强制暂停，通过查询资料懂得了System.exid(0);强制暂停，在判断超载过程虽然同上一次一样时实时判断，但是在当前载重的数值中时超载前一次的重量，且这是第一个坑，超载的输出不是在打印的输出单中，而是与非法数据相同，一旦超载立即停止输出，第二个坑在于判断超出最大值的输出，输出是在最大值到最小值之间，而最小值不是0而是1。且本人一开始还以为输出文字的最大值最小值，所以导致判断错误。解决过程为不断地控制变量法尝试测试用例
总结：
由于本次加入了4个类以及超载的输出判断方式又发生了改变，所以完成起来比较久，总体来说题目考察了对业务的理解能力以及测试结果判断能力，发现错误并且改正的能力。
改进建议
（1）在第二次题目中我出现了严重的失误，没有完全满足题目要求的情况下，就提交代码完成题目，以后要先通读全部要求，再动手写代码不再凭以往做题经验惯性写逻辑，分清实时判断、事后判断、停止时机、输出位置等不同规则，避免新旧代码逻辑混用出错。
（2）通过这三次迭代作业我发现自身对单一职责原则还是有些熟悉，且四大类间关系没有吃透，导致代码臃肿，主类处理业务逻辑太多。
（3）在测试方面，提前练习边界测试，平时练习主动测试零数据、最大值、最小值、非法数据等特殊情况，提升程序健壮性。
（4）代码注释的重要性，由于第一次代码几乎没有注释，导致第二次迭代时，总是翻来覆去找类，所以以后一定要督促自己养成写注释的好习惯。
总结
1.在本次迭代式作业中，我学到对业务要求进行模块化拆分和处理，符合SPR原则的代码编写，对于类之间的关系和封装更加熟练，我不再只追求 “代码能跑”，而是开始关注可读性、可维护性和健壮性，学会了用控制变量法调试 bug，也掌握了System.exit()这类流程控制语句。
2.学习到了代码不是写的越快越好，搭好合适的框架，设计合理且扁平健壮的代码才是好的基础，且一定要对问题进行仔细的拆分和理解，这样才能真正的解决问题。
对题目的改进建议：
在第一次测试中，选择排序和冒泡排序的微小差别是非常精彩的测试点，但像第三题，最小值题目给出0，答案却是1的误差错误很难被发现出来，希望以后可以加强题目和答案之间的严谨性。