第二次大作业-航空货运管理系统

一、引言

这作业太简单了，对比第一次大作业，但我还是学到不少，比如深入理解了类间关系，明白了抽象类和接口存在的意义。

二、作业分析

第一次作业如下：
7-3 NCHU_航空货运管理系统（类设计）
分数 60
中等
作者 段喜龙
单位 南昌航空大学
航空快递以速度快、安全性高成为急件或贵重物品的首选。本题目要求对航空货运管理系统进行类设计，具体说明参看说明文件。
OO第九周作业题目说明.pdf

输入格式:
按如下顺序分别输入客户信息、货物信息、航班信息以及订单信息。

客户编号
客户姓名
客户电话
客户地址
运送货物数量
[货物编号
货物名称
货物宽度
货物长度
货物高度
货物重量
]//[]内的内容输入次数取决于“运送货物数量”，输入不包含“[]”
航班号
航班起飞机场
航班降落机场
航班日期（格式为YYYY-MM-DD）
航班最大载重量
订单编号
订单日期（格式为YYYY-MM-DD）
发件人地址
发件人姓名
发件人电话
收件人地址
收件人姓名
收件人电话
输出格式:
如果订单中货物重量超过航班剩余载重量，程序输出The flight with flight number:航班号 has exceeded its load capacity and cannot carry the order. ，程序终止运行。
如果航班载重量可以承接该订单，输出如下：
客户：姓名(电话)订单信息如下：

航班号：
订单号：
订单日期：
发件人姓名：
发件人电话：
发件人地址：
收件人姓名：
收件人电话：
收件人地址：
订单总重量(kg)：
微信支付金额：

货物明细如下：

明细编号 货物名称 计费重量 计费费率 应交运费
1 ...
2 ...
注：输出中实型数均保留1位小数。

输入样例:
在这里给出一组输入。例如：

10001
郭靖
13807911234
南昌航空大学
2
101
发电机
80
60
40
80
102
信号发生器
55
70
60
45
MU1234
昌北国际机场
大兴国际机场
2025-04-22
1000
900001
2025-04-22
南昌大学
洪七公
18907912325
北京大学
黄药师
13607912546
输出样例:
在这里给出相应的输出。例如：

客户：郭靖(13807911234)订单信息如下：

航班号：MU1234
订单号：900001
订单日期：2025-04-22
发件人姓名：洪七公
发件人电话：18907912325
发件人地址：南昌大学
收件人姓名：黄药师
收件人电话：13607912546
收件人地址：北京大学
订单总重量(kg)：125.0
微信支付金额：3350.0

货物明细如下：

明细编号 货物名称 计费重量 计费费率 应交运费
1 发电机 80.0 25.0 2000.0
2 信号发生器 45.0 30.0 1350.0

第一次提交结果如下：

1.一个小问题是格式错误，The flight with flight number:航班号 has exceeded its load capacity and cannot carry the order.在has面前加个空格。比较无语。
2.第二个是理解问题，我先入为主地使用实际重量计算总重量。
public static void addItem(item it) {
ar.add(it);
totalWeight += it.getGrossWeight(); // 使用实际重量计算总重量
totalFee += it.getFee();
}
实际应使用体积重量和实际重量的较大值。
public static void addItem(item it) {
ar.add(it);
totalWeight += it.getWeight(); // 使用计费重量（体积重量和实际重量的较大值）计算总重量
totalFee += it.getFee();
}

7-3 NCHU_航空货运管理系统（继承与多态）
分数 50
较难
作者 段喜龙
单位 南昌航空大学
航空快递以速度快、安全性高成为急件或贵重物品的首选。本题目要求对航空货运管理系统进行类设计，具体说明参看说明文件。
OO第十二周作业题目说明.pdf

输入格式:
按如下顺序分别输入客户信息、货物信息、航班信息以及订单信息。

客户类型[可输入项：Individual/Corporate]
客户编号
客户姓名
客户电话
客户地址
货物类型[可输入项：Normal/Expedite/Dangerous]
运送货物数量
[货物编号
货物名称
货物宽度
货物长度
货物高度
货物重量
]//[]内的内容输入次数取决于“运送货物数量”，输入不包含“[]”
航班号
航班起飞机场
航班降落机场
航班日期（格式为YYYY-MM-DD）
航班最大载重量
订单编号
订单日期（格式为YYYY-MM-DD）
发件人地址
发件人姓名
发件人电话
收件人地址
收件人姓名
收件人电话
支付方式[可输入项：Wechat/ALiPay/Cash]
输出格式:
如果订单中货物重量超过航班剩余载重量，程序输出The flight with flight number:航班号 has exceeded its load capacity and cannot carry the order. ，程序终止运行。
如果航班载重量可以承接该订单，输出如下：
客户：姓名(电话)订单信息如下：

航班号：
订单号：
订单日期：
发件人姓名：
发件人电话：
发件人地址：
收件人姓名：
收件人电话：
收件人地址：
订单总重量(kg)：
[微信/支付宝/现金]支付金额：

货物明细如下：

明细编号 货物名称 计费重量 计费费率 应交运费
1 ...
2 ...
注：输出中实型数均保留1位小数。

输入样例:
在这里给出一组输入。例如：

Corporate
10001
郭靖
13807911234
南昌航空大学
Expedite
2
101
发电机
80
60
40
80
102
信号发生器
55
70
60
45
MU1234
昌北国际机场
大兴国际机场
2025-04-22
1000
900001
2025-04-22
南昌大学
洪七公
18907912325
北京大学
黄药师
13607912546
ALiPay
输出样例:
在这里给出相应的输出。例如：

客户：郭靖(13807911234)订单信息如下：

航班号：MU1234
订单号：900001
订单日期：2025-04-22
发件人姓名：洪七公
发件人电话：18907912325
发件人地址：南昌大学
收件人姓名：黄药师
收件人电话：13607912546
收件人地址：北京大学
订单总重量(kg)：125.0
支付宝支付金额：4360.0

货物明细如下：

明细编号 货物名称 计费重量 计费费率 应交运费
1 发电机 80.0 40.0 3200.0
2 信号发生器 45.0 50.0 2250.0

相比第一次增加了三个：
1.支付方式增多。
2.新增了货物类型，致使计算rate方式改变。
3.新增了客户类型，致使计算总金额改变。
我一遍过。

三、代码分析

1.第一次

Lines（行数）：221 ，表示代码文件的总行数 。
Statements（语句数）：149 ，指可执行语句数量 。
Branch Statements（分支语句数）：54 ，像 if、switch 等产生分支逻辑的语句数量 。
Method Call Statements（方法调用语句数）：57 ，代码中调用方法的语句数量 。
Percent Lines with Comments（注释行百分比）：2.7 ，即代码中注释行占总行数的比例 。
Classes and Interfaces（类和接口数）：6 ，文件中定义的类和接口总数 。
Methods per Class（平均每类方法数）：4.17 ，类和接口中方法的平均数量 。
Average Statements per Method（平均每个方法的语句数）：4.00 ，每个方法平均包含的语句数量 。
Line Number of Max Complexity Method（最大复杂度方法所在行号）：103 ，具有最高复杂度方法在文件中的行号 。

2.第二次

代码规模
Lines（283 行）：表明文件有一定规模，行数较多可能意味着代码逻辑复杂。在维护时，查找特定功能代码难度相对增加，可考虑进一步模块化拆分，提高可读性与可维护性。
Statements（58 条语句）：可执行语句数量不算多，但与行数对比，可能存在较多空行、注释行或声明行等非执行语句。
Method Call Statements（42 条方法调用语句）：方法调用语句占比高，说明代码通过调用各类方法实现功能，体现了较好的模块化思想。但也需关注方法间调用关系是否过于复杂，避免出现难以理解的调用链。
代码结构
Percent Branch Statements（5.2% 分支语句占比）：分支语句（如 if、else、switch 等）占比低，代码逻辑可能相对线性，较少复杂的条件判断。好处是代码执行路径较清晰，但也可能意味着功能不够灵活，应对复杂业务场景能力有限。
Classes and Interfaces（2 个类或接口）：文件中定义的类或接口数量较少，代码结构相对简单，便于理解和管理。不过，若项目规模扩大，可能需要进一步拆分和抽象，提升代码扩展性。
Methods per Class（平均每个类 2.00 个方法）：平均方法数较少，说明类的功能可能相对单一，符合高内聚原则。但也可能存在功能分散问题，需审视是否可将相关功能聚合到同一类中。
Average Statements per Method（每个方法平均 12.00 条语句）：方法平均语句数不算少，部分方法可能存在功能过于复杂的情况，可考虑拆分方法，降低单个方法的复杂度。
代码注释
Percent Lines with Comments（1.4% 注释行占比）：注释占比极低，这对代码可读性和可维护性极为不利。后续维护人员很难快速理解代码逻辑和功能，尤其是复杂算法或业务逻辑部分。建议及时添加详细注释，包括方法功能、参数含义、关键代码段作用等。
代码复杂度
Line Number of Most Complex Method（最复杂方法在第 6 行）：表明早期代码就出现了复杂度较高的方法。需深入查看该行及相关代码，是否存在嵌套循环、多层条件判断等复杂逻辑，考虑优化拆分。
Kiviat Graph（雷达图）：展示了平均复杂度（Avg Complexity）、平均深度（Avg Depth）、最大深度（Max Depth）、最大复杂度（Max Complexity）、每类方法数（Methods/Class）、平均每个方法的语句数（Avg Stmts/Method）、注释百分比（% Comments）等指标。从图中可直观对比各指标相对情况，判断代码整体复杂度分布。
Block Histogram（柱状图）：横坐标为代码块深度，纵坐标为语句数量，展示语句数量随代码块深度的分布。可以看出大部分语句集中在深度较低区域，但仍有部分语句深度较高，说明存在一定复杂度的代码块，需优化。
优化建议
添加注释：提高注释占比，对关键代码、方法、业务逻辑添加注释。
方法拆分：对语句较多、功能复杂的方法进行拆分，降低单个方法复杂度。
代码重构：根据业务逻辑，合理拆分或聚合类与方法，优化代码结构。

四、技术亮点及潜在问题

技术亮点

静态成员变量
goods类使用静态变量存储全局数据（如总重量、总费用），便于跨对象访问。
继承与复用
customer继承person类，复用基础信息字段，符合 DRY（Don't Repeat Yourself）原则。
费用自动计算
货物费用根据重量区间自动计算，业务逻辑封装在item类中，提高内聚性。

潜在问题

静态设计的局限性
goods类的静态属性导致系统无法同时处理多个订单（数据全局共享）。
改进建议：改为实例化对象管理单个订单，通过容器类管理多个订单。
输入验证缺失
未对用户输入进行有效性检查（如非数字输入、负数重量等）。
可能导致NumberFormatException或逻辑错误。
代码重复
flight类中发件人（p1）和收件人（p2）信息的输入逻辑重复。
可提取为工具方法或使用构造函数初始化。
国际化支持不足
输出信息为英文硬编码，未考虑多语言需求。

五、总结
该系统通过面向对象设计实现了基本的航空货运订单管理功能，结构清晰，但在输入验证、数据管理和扩展性方面存在改进空间。通过优化静态设计、增强输入处理和引入设计模式，可提升系统的健壮性和可维护性。