OO第一次博客作业

前言

本次总结分为三个作业，三次作业逐次迭代，难度也逐渐上升。第一次作业内容是航空器配载与货运管理系统，其中只涉及飞机，单个机舱，以及多个货物，题量较小，比较简单，第二次作业在第一次作业基础上增加了多个货舱（如前舱、后舱等），每个货舱有独立的最大载重和固定数量的装载位置，题量变大，难度提高很多，第三次作业在第一次作业的基础上增加了旅客，行李，以及货物的配平计算，题量最大，但难度没有提高太多。下面我将对三次作业进行详细分析

设计与分析

第一次作业

类图分析：

第一次作业的类图如下

Cargo 类用于封装货物名称和重量；LoadManifest 类有一个 ArrayList 货物列表，提供添加货物、显示货物以及获取列表的方法；Flight 类存储航班号、最大载重和计划载货数量，并通过 caltotal 方法计算当前货物总重量；CargoSorter 类实现选择排序算法，按货物重量从高到低对货物列表进行降序排列；Main 类是程序入口，首先从键盘读取航班信息（航班号、最大载重、货物数量），然后循环读取每个货物的名称和重量并添加到配载单中，计算并输出总重量，再对货物列表按重量排序，最后显示所有货物明细、总重量与最大载重的对比，并根据是否超载输出正常或警告的状态信息。其中Flight 类和 LoadManifest 类是依赖关系，CargoSorter 类和 LoadManifest 类是依赖关系，LoadManifest 类和 Cargo 类是聚合关系。

代码规模

第一次作业的代码规模如下

心得

通过完成本次作业的设计与实现，我对Java 面向对象程序设计有了更加深入的理解，也第一次真正体会到“单一职责原则（SRP）”在实际开发中的意义。

第二次作业

类图分析：

第二次作业的类图分析如下

第二次作业主要处理货舱、货物和航班之间的调配逻辑。其中Cargo类只存货物ID和重量，Position类用来表示货舱里的行列位置，CargoCompartment类表示一个货舱，里面有最大载重、一个货舱ID、一个货物列表，还有一个位置列表，代码中通过循环调用setPositions方法来往这个位置列表里塞Position对象，Flight类则负责组装航班信息，包括航班号、最大起飞重量、最大业载和多个货舱，LoadDispatcher类从所有货舱中把货物汇总并按重量降序排序，根据货物ID查找某个货物，InputValidator类有检查行列范围的方法，main方法按顺序读输入航班信息，货舱数量和每个货舱的ID，最大载重，行列数，接着读货物数量，每件货物指定名称、重量和要放入的货舱ID，并直接加进对应的货舱。然后调用LoadDispatcher类的方法先对所有货物按重量排序，再计算总重量，判断货舱当前重量加上该货物会不会超重。最后输出每个货舱的已装重量和状态，以及航班整体重量是否超过最大起飞重量和最大业载。其中CargoCompartment类和Position类是依赖关系，CargoCompartment类和Cargo类是聚合关系，Flight类和CargoCompartment类也是聚合关系，LoadDispatcher类和Flight类是依赖关系，LoadDispatcher类和Cargo类也是依赖关系，LoadDispatcher类和CargoCompartment类仍然是依赖关系。

代码规模

第二次作业的代码规模如下

心得

第二次作业由于自身原因导致只拿了七十分，有部分设计要求没有完全实现，三个测试用例也没有通过。写这次作业的时候对整体的设计没有很好的把握，导致写的时候混乱，想要修改功能的时候也无从下手。造成这次的原因可能是因为平时练习的代码量不够，同时没有理清类与类间的关系就动手去写。在以后的学习过程中应该加大练习量，同时看懂题目思路再动手写。这段代码有几个问题：首先是总重量计算错误，在最后统计航班总重量时，totalWeight = temp.getCurrentWeight(cargoArray)被写在货舱循环内部，这样会导致 totalWeight 每次都被覆盖，只保留最后一个货舱的计算结果，而不是全航班的真实总重量；其次是装载重量判断逻辑不严谨，在装载时用loaded列表来计算当前货舱重量，但这个列表是全局共享的，没有按货舱区分，会导致不同货舱之间的重量计算互相干扰，而且虽然写了InputValidator类，但main方法中没被使用，最后是整体设计上职责混乱，比如装载决策、统计都集中main方法中，代码扩展性一般。

第三次作业

类图分析

第三次作业的类图分析如下

第三次作业是在做一个航班载重与重心配平计算系统，其中Flight类负责保存航班信息、旅客列表以及两个货舱，CargoCompartment类表示货舱，包含最大载重、位置列表以及货物列表，并提供计算当前重量的方法，Cargo类是货物类，Passenger类和Luggage类是旅客及行李，Position类用于描述货舱位置，WeightBalanceCalculator类是核心计算模块，负责计算总重量、总力矩、重心CG以及安全性判断，并生成最终舱单报告；InputValidator类负责输入校验和数据录入；LoadDispatcher类对货物进行排序，在main方法中，程序先创建航班对象并初始化前舱和后舱，然后输入设置航班号、货舱位置和最大载重，再录入旅客重量和货物信息，并将货物分别装入前舱或后舱，最后调用WeightBalanceCalculator类中的generateLoadSheet方法输出配载报告。其中Flight类和CargoCompartment类是聚合关系，Flight类与Passenger类是聚合关系，CargoCompartment类和Position类是聚合关系，CargoCompartment类和Cargo类是聚合关系，Passenger类和Luggage类是组合关系，InputValidator类与flight类是依赖关系，InputValidator类和Position类是依赖关系，LoadDispatcher类和Cargo类是依赖关系，WeightBalanceCalculator类和Flight类是依赖关系，WeightBalanceCalculator类和CargoCompartment类是依赖关系。

代码规模

第三次作业的代码规模如下

心得

第三次作业在通过反复测试后，有一个测试点没有通过。尝试和同学的代码输入同样的多组测试数据，结果输出一模一样。我到现在都不知道为什么通不过最后一个测试点。但总而言之，这次作业比上次有所提升，提高代码练习量和冷静分析确实对作业有所帮助。这次作业让我从写功能代码慢慢转向按需求建模再写代码的思维方式，尤其是把重量、力矩、重心这些物理概念映射到对象和方法时，会更直观地理解程序的意义，而不仅仅是完成题目本身。

踩坑心得

第一次作业

第一次作业提交时出现了多次非零返回，是因为输入读取存在潜在问题，sc.nextLine() 和 sc.nextDouble()和sc.nextInt() 混用,但没有处理换行符，容易导致读取为空或错位。然后也出现了很多次编译错误。然后是出现多次部分正确，原因是因为写排序时使用了冒泡排序，导致当有两个重量相等的货物时，输出排序后货物列表的两个货物优先级与题目的答案不同，修改为选择排序后就能通过。最后也是最严重的一点，写代码时在类中创建ArrayList对象时忘记加private，导致虽然测试点都通过但是人工核查后只能拿六十分。

第二次作业

第二次作业由于自身原因导致只拿了七十分，有部分设计要求没有完全实现，三个测试用例也没有通过。写这次作业的时候对整体的设计没有很好的把握，导致写的时候混乱，想要修改功能的时候也无从下手。造成这次的原因可能是因为平时练习的代码量不够，同时没有理清类与类间的关系就动手去写。在以后的学习过程中应该加大练习量，同时看懂题目思路再动手写。这段代码有几个问题：首先是总重量计算错误，在最后统计航班总重量时，totalWeight = temp.getCurrentWeight(cargoArray)被写在货舱循环内部，这样会导致 totalWeight 每次都被覆盖，只保留最后一个货舱的计算结果，而不是全航班的真实总重量；其次是装载重量判断逻辑不严谨，在装载时用loaded列表来计算当前货舱重量，但这个列表是全局共享的，没有按货舱区分，会导致不同货舱之间的重量计算互相干扰，而且虽然写了InputValidator类，但main方法中没被使用，最后是整体设计上职责混乱，比如装载决策、统计都集中main方法中，代码扩展性一般。

第三次作业

第三次作业由于是因为在eclipse上写完再上传到pta的，所以pta的提交没出现什么语法错误。我总结了写第三次作业时出现的问题，首先是list创建新对象是也是用ArrayList，然后是乘客和行李之间要建立多个行李时应该把定义行李变量这一行为放到循环里面，再就是当定义了一个ArrayList数组时，不能直接用.get(i).set(...)进行赋值，应该先定义再输入。然后题目中的最小值不是零而是一，可能因为货舱中没有货物时会导致重量失衡。最开始我因为看到题目中要求写排序，下意识得以为写了就要用，于是在主函数中对数组进行排序，导致测试点过不了，最后发现其实不需要在主函数中排序。最后就是写输出语句时没看清要求中写的，导致输出时漏了四个字。

改进建议

第一次作业

首先Flight类的里面的n和LoadManifestL实际没有参与核心逻辑，完全可以删掉，而且caltotal方法虽然放在Flight类里，但它实际上是对LoadManifest的计算方法，职责其实更适合独立成工具类或放在LoadManifest中。

第二次作业

首先是LoadDispatcher的职责分配不完善，它既负责排序，又被main方法使用来驱动装载流程，但实际上它只进行汇总和排序，真正的装载逻辑却写在main 里，导致业务流程分散，不利于维护。

第三次作业

首先是 InputValidator 的职责过重，它既负责输入、校验，又负责构建 Flight 和两个货舱对象。另外LoadDispatcher.sortCargos使用的是冒泡排序，但循环条件写成j < cargo.size() - 1，没有考虑逐轮缩减范围，效率不高，应该改成j < cargo.size() - 1 - i。

总结

这三次作业是对飞行器载重的逐渐迭代，通过本阶段三次作业的完成，我对 Java 面向对象程序设计的理解有了明显提升，对单一职责和类与类之间的关系有了更深刻的力竭，也逐渐从只会写功能性代码转向了先分析需求再进行设计的思维方式。三次作业虽然都围绕航空器载重展开，但每一次迭代都在原有基础上增加了新的业务需求和新的类之间关系，使我逐步体会到软件开发客户需求变化的完整过程。当然，目前仍有很多地方需要进一步学习和研究。首先是面向对象设计能力还不够成熟，很多时候容易把大量逻辑堆积到main方法或者某一个类中，对职责拆分的理解还需要加强。其次，对集合类、泛型、异常处理等 Java 基础知识的掌握还不够深入，导致很多代码写法不够规范。应该加强练习。对教师、课程、作业、实验、课上及课下组织方式等方面的改进建议及意见：暂无