NCHU_航空货运管理系统-第二次bolg作业-java

一、前言

随着现代物流行业的快速发展，航空货运作为重要的运输方式之一，对信息系统的依赖日益增强。本次项目通过两次迭代开发，逐步构建了一个航空货运管理系统原型。第一次迭代聚焦于基础类结构的设计与实现，第二次迭代则引入了继承与多态特性，进一步完善系统功能。本报告旨在全面总结两次迭代开发过程中的经验教训，分析代码质量，并提出改进建议。
通过对比分析两次迭代的代码复杂度、结构设计和问题解决过程，我们能够深入理解面向对象设计原则在实际项目中的应用，掌握处理复杂业务逻辑的方法，并认识到代码可维护性的重要性。

二、航空货运管理系统

1.第一次迭代作业（类设计）

1.1 测试样例

输入：

输出：

1.2 核心问题分析

(1)收、发件人的电话、地址、姓名，对应错位

输入：

输出：

原因：
addressor类、recipient类、client类，共同继承user类，但user只有一个构造方法，且client类的姓名、电话、地址的输入与addressor类、recipient类的不同，
导致输入错位。
解决方案：
再构建一个构造方法，添加形参format，区分client类与addressor类、recipient类的输入不同。

(2)异常输入时未正确输出

输入：

输出：

原因：
当输入货物总重量超出航班最大运载重量时，其他部分照常运行并输出，订单总重量输出变为“The flight with flight number:%shas exceeded its load capacity and cannot carry the order.”
解决方案：
调整代码结构，先计算总重量，再进行异常输入判断，最后再输出。

(3)异常输入格式错误

这个卡了我很久，完全复制题目的异常输出，也还是格式错误。

后来我才知道，题目中的异常输出需要在has前添加空格。

1.3 类结构设计

1.4 代码复杂度分析

(1)类与方法结构

1.类和接口总数：7 个
2.平均每个类包含的方法数：7.71 个
3.平均每个方法的语句数：2.11 条，表明大多数方法逻辑较简单

(2)复杂度分析

1.最复杂方法：Main.main()，复杂度为 3（最大值）
2.其他方法复杂度基本为 1，表示逻辑较为线性，分支较少
3.平均复杂度：1.06，整体控制良好

(3)关键方法分析

Main.main()
1.复杂度：3
2.语句数：37 条
3.调用其他方法次数：34 次
4.块深度：3
建议：
方法职责过多，应考虑拆分逻辑，遵循单一职责原则
可将部分逻辑封装到独立方法或服务类中，提升可读性和测试覆盖率

(4)块深度分布

块深度	语句数
0	9
1	77
2	99
3	15
4+	0

1.最大块嵌套深度为 3，出现在 Main.main() 和 order.show() 中
2.嵌套层级适中，但建议避免超过 3 层的嵌套逻辑，保持代码清晰易读

(5)优点总结

1.大多数方法复杂度低（为 1），逻辑清晰
2.方法粒度较小，便于理解和维护
3.类设计合理，方法数量适中

(6)改进建议

1.拆分主方法：Main.main() 过于庞大，建议拆分为多个子方法或使用命令模式
2.优化 order.show() 和 goods.goods()：适当解耦内部调用，减少方法依赖
3.提高可测试性：通过接口抽象或依赖注入方式降低类间耦合度

2.第二次迭代作业（继承与多态）

2.1 测试样例

输入：

输出：

2.2 核心问题分析

(1)应交运费输出错误

输入：

输出：

原因：
输出了打折后的钱。
解决方案：
调整代码结构，先计算总重量，再计算打折后的钱，最后再输出。

2.3 类结构设计