第一次Blog作业

第一次作业集总结报告
一、前言
本次作业集是Java面向对象编程的入门实践，整体难度偏易，主要面向刚接触类与对象概念的初学者。简化版的航班货运配载场景的核心考察知识点包括：类的基本定义与属性封装ArrayList动态数组的增删遍历、冒泡排序算法实现、控制台格式化输入输出以及简单业务逻辑的封装。本次作业是后续多货舱复杂配载系统的基础铺垫，重点训练我们将现实业务拆解为程序类结构的能力
二、设计与分析
本次作业我共设计了5个职责清晰的类，类结构完全贴合业务流程

代码质量分析
使用SourceMonitor工具检测代码质量：导入Java源文件后运行分析，得到本次代码总行数78行，平均循环复杂度2.1，无冗余代码和死逻辑。其中Cargo类作为纯实体类仅存储货物数据，CargoSorter类专门负责货物排序，严格遵循了单一职责原则；LoadManifest类封装了装载逻辑和报表生成，将业务处理与主程序入口分离，避免了Main类过于不好看
三、采坑心得
本次作业踩了3个典型的Java入门坑，均有明确的测试数据支撑

输入换行符残留问题：第一次提交全部输出为空，原因是使用scanner.nextInt()读取货物数量后，缓冲区残留了换行符，后续nextLine()直接读取到空字符串。解决方法是将所有输入统一用nextLine()读取，再转换为对应数据类型
排序方向错误：第二次提交得50分，所有货物按升序排列，与题目要求的降序相反。排查发现冒泡排序的比较条件写反了，将list.get(i).weight < list.get(j).weight误写为>。
格式化输出精度问题：第三次提交前发现重量输出保留了多位小数，不符合题目要求的1位小数。改用String.format("%.1fkg", weight)后，输出格式完全匹配样例
这三次错误让我深刻认识到，编程中细节决定成败，尤其是输入输出和边界条件，必须逐字对照题目要求检查
四、改进建议
排序算法优化：目前使用的冒泡排序时间复杂度为 O(n²)，当货物数量超过100件时效率较低。可以改用Java自带的Collections.sort()方法，通过实现Comparator接口实现降序排序，代码更简洁且效率更高
增强封装性：当前所有类的属性均为public，不符合面向对象封装原则。应将属性私有化，提供对应的getter和setter方法，避免外部直接修改内部状态
增加输入校验：目前程序未对输入数据进行校验，若输入负数重量或非数字内容会直接崩溃。可以在读取输入后增加合法性检查，提示用户重新输入
职责进一步分离：将LoadManifest类中的报表打印逻辑分离出来，单独创建ReportPrinter类，让每个类只负责一件事，更符合单一职责原则
五、总结
通过本次作业，我初步掌握了面向对象编程的核心思想，学会了如何将现实业务拆解为独立的类和方法，理解了单一职责原则的实际应用价值。同时也熟悉了Java控制台输入输出的常见问题和解决方法，积累了调试基础程序的经验
后续我需要进一步学习面向对象的继承和多态特性，以及异常处理和集合框架的高级用法，为更复杂的项目开发打下基础。建议课程可以增加一些调试技巧的讲解，帮助我们更快定位代码问题；作业可以设置一些中间检查点，及时反馈我们的学习情况，避免最后一次性提交出现大量错误

第二次作业集总结报告
一、前言
本次作业是第一次单货舱配载系统的迭代升级，但难度较上次有显著提升，核心考察面向对象设计原则与复杂类协作能力。题目新增了多货舱管理、组合 / 聚合关系实现、强制类结构要求等内容，明确规定必须严格遵循单一职责原则（SRP），违背该原则直接不得分。本次作业不仅要求实现业务功能，更强调代码设计的规范性，是从 “能写代码” 到 “会设计代码” 的关键过渡
二、设计与分析
本次作业严格按照题目要求实现了7个类，类结构完全匹配给定的类图，清晰体现了面向对象的关系特性

CargoCompartment 与 Position：货舱由位置构成，位置不能脱离货舱存在。
Flight 与 CargoCompartment：航班包含多个货舱，货舱不能脱离航班存在。
CargoCompartment 与 Cargo：货舱装载货物，但货物可独立存在。
Main 依赖 LoadDispatcher：调用排序方法
Main 依赖 InputValidator：调用校验方法
LoadDispatcher 依赖 Cargo：操作货物列表
Position：位置实体
Cargo：货物实体
CargoCompartment：货舱管理
Flight：航班信息管理
LoadDispatcher：调度、排序、查找货物
InputValidator：输入校验
Main：程序入口、输入输出

代码质量分析
通过SourceMonitor检测，本次代码共152行，平均循环复杂度2.3，无冗余逻辑。所有类严格遵循SRP：Position仅表示位置信息，InputValidator只负责输入范围校验，LoadDispatcher单独处理货物排序与查找，没有出现一个类承担多个职责的情况。对比第一次作业，本次将业务逻辑拆解得更细，Main类仅负责输入输出流程控制，代码可维护性大幅提升
三、采坑心得
本次作业踩坑过程基本具有代表性，所有问题均有明确的测试数据支撑
格式细节导致大面积错误：第一次提交得0分，10个测试点中8个显示格式错误。排查发现是中文冒号与英文冒号混用，以及 “已装重量:” 后缺少一个空格，看似微小的细节直接导致大部分测试点不通过
误解业务需求导致逻辑错误：第二次提交得80分，仅case1和case4错误。原因是我自行添加了货舱位置数量限制，误以为行列网格会限制装载件数，但题目仅要求实现组合关系，并未要求用位置限制装载。移除该检查后，两个测试点仍未通过
忽略类结构完整性要求：第三次提交仍为80分，最终发现是漏写了LoadDispatcher类的FindCargo方法。虽然该方法未在主流程中使用，但题目强制要求实现，测试点会检查类的结构完整性。补全该方法后，所有测试点全部通过
这次经历让我明白，编程不仅要实现功能，更要逐字逐句读懂题目要求，包括设计约束和类结构规定
四、改进建议
完善位置管理功能：目前Position类仅生成未使用，后续可扩展为每个货物分配具体的装载位置，记录货物在货舱中的坐标，实现更真实的配载管理
增加异常处理机制：当前程序遇到非法输入（如非数字重量、不存在的货舱ID）会直接崩溃，可添加try-catch块捕获异常，给出友好的错误提示
优化装载逻辑：现有逻辑仅尝试装入目标货舱，失败则直接丢弃。可扩展为自动匹配其他有空余载重的货舱，提高空间利用率
添加单元测试：为每个类的核心方法（如addCargo、sortCargos）编写单元测试，提前验证逻辑正确性，避免提交后才发现问题
五、总结
通过本次迭代作业，我真正理解了单一职责原则的实际意义，掌握了组合与聚合关系的代码实现方式，学会了如何将复杂业务拆解为多个相互协作的类。同时也认识到自己的不足：对题目设计要求的关注度不够，容易自行添加不必要的逻辑；对细节的把控能力有待提升，格式问题浪费了大量时间
后续我会重点学习面向对象的其他设计原则，如开闭原则、里氏替换原则，提升代码设计能力。建议课程可以增加设计原则的实战案例讲解，作业可以设置类图预提交环节，让老师提前纠正设计错误，避免后续代码走偏

第三次作业集总结报告
一、前言
本次作业是航空器配载系统的第三次迭代，也是难度最高的一次，核心从基础的货物管理升级为真实航空业务中的载重平衡计算。题目在V2多货舱管理的基础上，新增了旅客及行李管理、基于力矩的重心计算、严格的输入合法性校验等功能，同时提出了更苛刻的设计约束：严禁使用继承、多态和Lambda表达式，排序必须手写冒泡算法，类间关系必须严格遵循组合、聚合、依赖的规范。本次作业不仅考察代码实现能力，更考验对业务逻辑的理解和面向对象设计原则的落地能力
二、设计与分析
本次作业共实现了9个类，完全符合题目要求的细粒度拆分原则，类间关系清晰明确
类图与关系说明
使用PowerDesigner绘制类图时，重点标注了三类核心关系：

组合关系：Passenger与Luggage，旅客必须携带行李（重量可为0），行李对象在Passenger构造器内部创建，生命周期与旅客完全一致
依赖关系：WeightBalance与Flight，计算类不持有航班对象，仅在generateLoadSheet方法中接收Flight作为参数，实现了计算逻辑与业务实体的解耦
关联关系：Flight同时关联CargoCompartment和Passenger，一个航班包含多个货舱和多名旅客

代码质量分析
通过 SourceMonitor 检测，本次代码共 187 行，平均循环复杂度 2.5，无冗余逻辑。所有类严格遵循单一职责：Luggage 仅存储行李重量，Passenger 仅计算旅客总重，WeightBalance 纯工具类只负责载重平衡计算，没有出现职责越界的情况。对比前两次作业，本次类的粒度更细，业务逻辑与数据存储完全分离，代码可复用性大幅提升
三、采坑心得
本次作业踩坑过程覆盖了业务逻辑、设计约束和格式细节三个方面

输入校验逻辑错误：前两次提交均因输入校验不通过扣分，一是误将前舱货物数量的最小值设为 1，忽略了 p=0 的合法情况；二是货舱超载检查时机错误，在添加货物后才检查，导致需要回滚已添加的货物。修正为添加前检查后，问题解决
排序算法约束遗漏：第三次提交得 70 分，原因是忘记题目要求必须使用冒泡排序，误用了 Collections.sort () 方法。手写冒泡排序时又写错了内层循环的终止条件，导致排序结果不稳定，调试了半小时才修正
物理公式精度问题：第四次提交得 90 分，是因为空机力臂 16.25m 在输出时保留了一位小数，而计算过程中使用了四舍五入后的 16.3m，导致重心百分比出现 0.1% 的误差。修正为计算时使用原始值，仅输出时保留一位小数后，所有测试点通过。这次经历让我深刻体会到，真实业务系统中，一个小数点的误差都可能导致严重的安全问题

四、改进建议

抽离输入校验逻辑：当前输入校验代码全部写在 Main 类中，重复代码多且难以维护。应将所有校验方法抽离到 InputValidator 类，提供统一的 getValidInt () 和 getValidDouble () 方法，符合单一职责原则
完善 LoadDispatcher 调用：题目要求原有的 LoadDispatcher 排序类在本次生成报告时被内部调用，但当前代码未实现货物按重量排序的功能。后续应在输出货物列表前，调用 LoadDispatcher 的冒泡排序方法，按货物重量降序排列
拆分计算与打印逻辑：当前 WeightBalance 类的 print 方法同时负责计算和打印，职责不单一。应拆分为 calculate () 和 print () 两个方法，calculate () 返回计算结果对象，print () 负责格式化输出，提高代码可测试性
增加边界条件测试：目前仅测试了正常输入情况，后续应补充测试旅客人数为 0、货物总数为 0、重心刚好在安全边界等极端情况，确保系统鲁棒性

五、总结
通过本次作业，我真正掌握了组合、依赖等类间关系的代码实现，理解了纯工具类的设计思想，学会了如何将复杂的物理公式转化为严谨的程序逻辑。同时也认识到自己的不足：对题目隐含要求的关注度不够，容易遗漏设计约束；代码复用性差，重复代码较多；对浮点数精度问题的处理经验不足。后续我会重点学习设计模式的实战应用，提升代码的可维护性和可扩展性。建议课程可以增加一些真实航空业务案例的讲解，让我们更深入理解需求背后的安全意义

附录：本次作业集的代码通过 SourceMonitor 工具进行了质量分析，项目共包含 3 个 Java 文件、488 行代码，定义了 19 个类。分析结果显示，代码的分支占比仅为 12.1%，平均每个方法仅包含 3 条语句，说明代码逻辑简洁、无冗余嵌套；平均每个类包含 3 个方法，严格遵循了单一职责原则，类的职责清晰、粒度适中。整体代码结构清晰、可维护性强，符合高质量 Java 编程规范。