面向对象作业集1~3的总结
一、前言：
截至目前，一共做了三次迭代作业，难度呈阶梯式上升，从基础单货舱管理逐步扩展至多货舱、旅客行李、重心配平计算，现在便来总结一下这三个作业集的知识点、题量、难度等情况。
（1）首先是作业集1：其中的知识点包括Java的基础语法、类的设计与封装、单一职责原则、类间关系以及排序算法，依次来实现单货舱航班是否超载的基础货运配载系统，题量很少，5个类和差不多100行的代码就能够解决这个作业集1，难度属于偏简单，非常适合我们刚开始学Java的学生来练习。
（2）其次是作业集2：其中的知识点包括Java的基础语法、类的设计与封装、单一职责原则、类间关系、结合集合排序输入校验与多层超载判断，以此来实现多货舱的航班货运配载管理系统，题量偏中，在作业集1的基础上添加了Position和InputValidator这2个类，需要7个类和差不多280行的代码来解决它，难度属于中等，可以进一步提升我们自己。
（3）最后是作业集3：迭代3是在迭代2的基础上，引入旅客与行李管理、力矩重心配平计算，结合严格输入校验与冒泡排序，基于单一职责原则实现的航空器载重平衡与重心安全评估系统，题量偏大，在作业集2的基础上多添加了3个类，分别是Passenger、Luggage和WeightBalanceCalculator三个类，同时还要对原来的InputValidator类进行优化，难度属于偏难。
二、设计与分析
（一）迭代 1：基础单货舱货运配载系统
- 类图设计
使用 PowerDesigner 绘制的类图如下：
Cargo类：仅封装货物的名称与重量，提供构造方法与 getter 方法，不包含任何业务逻辑，是纯数据载体。
Flight类：仅封装航班的核心信息（航班号、最大业载重量），并持有LoadManifest配载清单对象，不直接处理货物装载逻辑。
LoadManifest类：仅负责管理航班的货物列表，实现货物添加、总重量计算、超载判断的核心逻辑。
CargoSorter类：仅负责货物的排序功能，实现按重量从高到低的降序排序，与业务逻辑解耦。
2. 源码分析（基于 SourceMonitor 报告）
通过 SourceMonitor 工具对迭代 1 的代码进行分析，结果如下：
类耦合度：类之间仅通过方法调用关联，无直接依赖，耦合度低，内聚度高。LoadManifest通过组合Flight对象获取最大载重，而非直接持有其属性，符合面向对象设计规范。
3. 设计心得
迭代 1 让我第一次真正理解了 “单一职责原则” 的实践意义。最初的设计中，我曾将排序逻辑写在LoadManifest类中，导致该类同时承担了 “货物管理” 和 “排序” 两项职责，修改排序规则时必须改动LoadManifest类，违反了 SRP 原则。调整后，将排序逻辑剥离到CargoSorter类中，代码的可维护性显著提升。
（二）迭代 2：多货舱管理与重量排序装载系统
- 类图设计
使用 PowerDesigner 绘制的类图如下：
Position类：表示货舱中的一个位置（行、列），提供getPosName()方法，仅封装位置信息，无业务逻辑。
CargoCompartment类：货舱核心类，包含货舱 ID、最大载重、位置列表（组合关系，货舱创建时内部生成）、货物列表（聚合关系，货物可独立存在），提供addCargo()、getCurrentWeight()方法。
Flight类：新增List
LoadDispatcher类：调度类，负责货物排序、货舱查找、装载调度，解耦主流程与业务逻辑。
InputValidator类：输入校验类，提供整数、浮点数的范围校验方法，统一处理非法输入。
2. 源码分析（基于 SourceMonitor 报告）
迭代 2 的代码分析结果：
类耦合度：Flight类依赖CargoCompartment，LoadDispatcher依赖Cargo和CargoCompartment，依赖关系清晰，耦合度低。
3. 设计心得
迭代 2 的核心收获是理解了组合与聚合关系的区别，以及工具类解耦的重要性。
（三）迭代 3：航空器载重平衡与重心配平系统
- 类图设计
使用 PowerDesigner 绘制的类图如下：
Luggage类：仅负责记录行李重量，无其他业务逻辑，作为Passenger的内部组合对象。
Passenger类：管理旅客姓名、行李重量，计算旅客总重量（含标准体重）。
WeightBalanceCalculator类：仅负责载重平衡计算，作为工具类，计算总重量、总力矩、重心、% MAC 并判断安全状态。
同时，原有的Flight类新增List
2. 源码分析（基于 SourceMonitor 报告）
迭代 3 的代码分析结果：
类耦合度：WeightBalanceCalculator仅依赖Flight、Passenger、CargoCompartment类，无成员变量，依赖关系清晰；Passenger与Luggage为强耦合的组合关系，内聚度高。
3. 设计心得
通过输入校验、异常处理，提升了程序的健壮性，避免了非法输入导致的程序崩溃。
三、采坑心得
（一）输入处理相关问题
Scanner残留换行符问题：
问题表现：迭代 1 和迭代 2 中，使用scanner.nextDouble()读取数值后，调用scanner.nextLine()读取字符串时，读取到空字符串，导致程序崩溃。
原因分析：nextDouble()只会读取数值，不会吸收换行符，换行符会残留在输入缓冲区中，被后续的nextLine()读取。
解决方案：在读取数值类型后，额外调用一次scanner.nextLine()吸收残留换行符；或统一使用BufferedReader读取整行输入，再手动解析数据。
测试结果：调整输入处理逻辑后，所有样例输入均可正常读取，无空字符串问题。
（二）类设计与关系问题
SRP 原则违反问题：
问题表现：迭代 1 初期设计中，将货物排序逻辑写在LoadManifest类中，导致该类同时承担 “货物管理” 和 “排序” 两项职责，违反了单一职责原则。
原因分析：对 SRP 原则的理解不深入，认为 “把逻辑写在一起方便”，忽略了代码的可维护性和可扩展性。
解决方案：将排序逻辑剥离到CargoSorter类中，每个类仅承担一项职责，修改排序规则时无需改动LoadManifest类。
圈复杂度对比：调整前LoadManifest类圈复杂度为 5，调整后降至 2，代码可读性显著提升。
（三）测试与调试问题
测试用例覆盖不全问题：
问题表现：迭代 2 和迭代 3 中，部分边界场景未通过测试，导致程序异常。
原因分析：仅使用题目提供的样例输入进行测试，未设计边界用例和异常用例，无法发现潜在问题。
解决方案：补充多组测试用例，包括正常场景、边界场景、负数输入逐一验证程序逻辑。
测试覆盖率：补充用例后，测试覆盖率从 50% 提升至 90%，所有边界场景均能正常处理。
四、改进建议
（一）代码复用性优化
输入校验逻辑封装：三次作业中，InputValidator类的校验逻辑存在重复，可进一步封装为通用校验方法，支持不同范围、不同类型的校验，减少代码冗余。
（二）类设计优化
LoadDispatcher职责拆分：当前LoadDispatcher同时承担排序和货舱查找两项职责，可拆分为CargoSorter和CompartmentFinder两个工具类，进一步遵循单一职责原则。
（三）用户体验优化
当前程序的输出信息较为简洁，用户难以快速定位问题。后续可优化输出格式，增加更多提示信息
五、总结
（一）学习收获
1.养成规范写代码的习惯：
经过三次作业的打磨，我改掉了以前代码随意编写、不注重格式、不写注释的坏习惯，现在写代码会注意缩进排版，给核心代码加上简单注释，让别人能看懂，自己日后回看也能快速理清思路。
2.学会拆分复杂项目需求：
面对迭代三这种功能繁多、逻辑复杂的大作业，我不再感到无从下手，而是学会把整体大需求拆分成一个个小功能，先完成数据录入，再完成数据排序，接着完成货物分配，最后完成重心计算，逐个击破，慢慢整合拼接成完整程序。
（二）待提升方向
- 多加实操练习，提升代码熟练度：
课后不再只局限于完成老师布置的作业，多找同类型的面向对象小题反复练习，熟练各类语法和常用功能写法，提升敲代码速度，做到常见功能随手就能写出，夯实基本功。 - 注重细节，强化程序完整性：
今后编写程序时，主动加入数据校验、异常情况提醒、边界值判断等功能，不再只满足基础功能实现，尽量让自己写出来的程序更加完善、稳定、贴近实际应用软件的标准。 - 及时复盘总结，整理错题错码：
把三次作业里自己经常写错的逻辑、容易踩坑的知识点整理记录下来，空闲时间反复翻看复盘，避免以后犯同样的错误，一点点补齐自己学习中的薄弱之处。
（三）课程与作业建议
1.这三次作业的难度安排得挺合理的，一步一步慢慢变难，知识点也是一环扣一环。而且作业选的场景都很贴近真实的航空业务，让我们真正明白了编程在实际工作中到底有啥用，就是给的时间比较多，总给人一种时间还长，晚点再写的感觉。
2.对于课程，我认为应该提前告知学生要讲的内容，让我们做好预习工作，这样课上就可以少花点时间在讲知识点上了，花更多的时间去讲例题，然后让同学们自己去实践，毕竟实践才是检验真理的唯一标准。
总的来说，这三次作业对我来说特别重要，算是软件工程学习路上的一个大台阶。不仅让我的编程水平上去了，更重要的是锻炼了我的系统设计思维和专业素养，给后面学习和干活打下了特别扎实的基础。
浙公网安备 33010602011771号