Blog2-航空货运管理系统

前言：
在面向对象课程的学习进程中，Java 题目集成为检验知识掌握程度与实践能力的重要载体，其中第八、九次作业中的 “航空货运管理系统” 开发任务，更是极具挑战性与学习价值的实践项目。
这两次作业围绕航空货运管理系统，分阶段逐步深入。首次作业聚焦类设计，要求严格遵循单一职责、里氏代换、开闭、合成复用四大原则，着重培养对基础设计原则的理解与应用能力；第二次作业则在前者基础上，引入依赖倒转原则，并强调继承与多态的运用，同时拓展支付方式、用户、货物等业务场景，大幅提升了题目的复杂性与综合性。从最初面对庞大业务逻辑时对类图设计、继承与聚集选择的迷茫，到通过对设计原则的深入钻研与反复实践，逐步实现系统架构的清晰化与功能的灵活拓展，这一过程不仅深化了对六大设计原则（单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、开闭原则、迪米特法则）的认知，更显著增强了运用继承、接口和多态处理类间关系的能力。相较于此前的电梯作业，航空货运管理系统虽在逻辑理解上稍显友好，却对代码的可复用性与可拓展性提出了更高要求，成为提升编程思维与系统设计能力的关键契机。
设计与分析：
第一次作业分析：
航空货运管理系统（类设计）：
题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载
重量）
客户填写货运订单并进行支付，需要提供如下信息：
客户信息（姓名，电话号码等）
货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
支付方式（支付宝支付、微信支付、现金支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独
计费。
程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信
息报表及货物明细报表。
题目要求
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开
闭原则以及合成复用原则、依赖倒转原则
输入格式:
按如下顺序分别输入客户信息、货物信息、航班信息以及订单信息。
客户编号
客户姓名
客户电话
客户地址
运送货物数量
[货物编号
货物名称
货物宽度
货物长度
货物高度
货物重量
]//[]内的内容输入次数取决于“运送货物数量”，输入不包含“[]”
航班号
航班起飞机场
航班降落机场
航班日期（格式为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
题目分析：
本题聚焦航空货运管理系统的空运费计算，全面考查面向对象设计原则的实践应用。系统需通过控制台接收航班、客户、货物、运输方式及支付方式等多维度数据，构建支持多件货物独立计费的订单处理系统，并按要求输出订单及货物明细报表。初始设计仅考虑订单类，后经迭代优化，基于单一职责原则引入订单明细类，将功能模块进行合理拆分。解题的关键在于：运用单一职责原则确保类的功能专注性，通过里氏代换原则保障继承体系的行为一致性，遵循开闭原则实现系统对扩展的开放性，采用合成复用原则提升代码复用的灵活性与系统架构的稳定性。
类图：

代码分析：

从Kiviat Graph指数看，类均方法数相对适中，说明在类的功能划分上有一定合理性，初步实现了功能模块化。但“Max Complexity”（最大复杂度）和“Max Depth”（最大深度）指标表现欠佳，意味着存在部分方法复杂度高、逻辑嵌套深的问题。同时，“Avg Stmts/Method”（平均语句/方法）数值与其他指标综合来看，或暗示方法内语句存在一定冗余，且“% Comments”（注释占比）为0，严重影响代码可读性与可维护性。
第二次作业分析：
航空货运管理系统（继承与多态）:
题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载
重量）
客户填写货运订单并进行支付，需要提供如下信息：
客户信息（姓名，电话号码等）
货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
支付方式（支付宝支付、微信支付、现金支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独
计费。
程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信
息报表及货物明细报表。
四、题目要求
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开
闭原则以及合成复用原则、依赖倒转原则
输入格式:
按如下顺序分别输入客户信息、货物信息、航班信息以及订单信息。

客户类型[可输入项：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
代码分析：

从代码度量数据看，分支语句占比12.4% ，表明代码中存在一定条件判断逻辑，但可能有优化空间。方法调用语句仅9条，或说明模块间交互相对较少。注释占比为0% ，严重影响代码可读性与可维护性。有9个类和接口，类均方法数达11.00 ，方法平均语句数1.57 ，意味着类功能较丰富但方法内语句简洁。

最复杂方法为 `ExpediteRate.getPhone()，最大复杂度和最大深度均为5 ，平均复杂度2.05 、平均深度2.07 ，说明部分方法逻辑较复杂，整体代码结构有一定深度和复杂度.
踩坑心得：
在航空货运管理系统作业里，我踩过不少坑，也积累了诸多经验。

类设计上，前期未独立支付类，阻碍支付方式扩展，让我明白继承与多态的重要。开始只考虑订单类和货物类，代码耦合度高，问题难排查，凸显良好类设计的关键。后来虽优化，但订单类仍职责过多，没设订单明细类，影响代码可扩展性与可读性。计算总重量时，错用实际重量而非体积重量，这告诉我代码要严格按业务需求写。

输入处理时，用户输入格式要求高，读货物数量等，非数字字符会让程序崩溃。加输入校验，判断格式并提示重输，解决了问题。混合用nextLine()和数值输入，会留换行符致输入错位，用sc.nextLine()消耗换行符才解决。

测试时，运费计算不对，发现是体积重量单位换算错，增加边界测试用例才确保准确。
接口使用方面，开始不熟悉，题目集8用抽象类，限制功能，题目集9改成接口，增强了系统灵活性。

这次作业的经历，让我在编程各方面有了更深理解，这些经验会助力我以后的学习。
改进建议：
代码结构优化：遵循单一职责原则，将订单类中货物管理、费率计算等逻辑拆分至独立的订单明细类与费率策略类，每个方法语句控制在 20 行内，避免职责混杂。采用策略模式替代多层if-else，如将货物计费逻辑封装为独立策略类，提升扩展性与逻辑清晰度。
可读性增强：在关键逻辑（如体积重量计算、支付方式适配）和复杂方法（如订单总金额汇总）添加必要注释，说明业务规则（如 “体积重量 = 长 × 宽 × 高 / 6000，取整数部分”），避免隐含逻辑影响维护。
耦合度降低：通过抽象类 / 接口规范类间交互，区分继承（is-a 关系）与聚合（has-a 关系），如航班与货物为聚合而非继承，减少不必要依赖。
总结：

在航空货运管理系统开发中，需注重面向对象设计原则。拆分订单、货物明细等独立类，降低耦合，用策略模式优化计费逻辑。关键处添加注释，拆分复杂方法，控制语句行数。明确继承与聚合区别，通过代码审查和全场景测试保障质量，提升代码可读性与扩展性。