航空货运管理系统8-9次作业

一、前言
这两次作业的难度设置于我而言较为适宜，初次接触时，因对题目的整体框架与逻辑脉络尚不清晰，思维一度陷入混沌状态，未能迅速构建起有效的解题路径。而第二次作业在延续核心要求的基础上，仅对部分条件进行了适度延伸，这种连贯性为我提供了重新审视问题的契机。在二次思考过程中，我得以对初始阶段模糊的思路进行系统性梳理，逐步在脑海中搭建起完整的逻辑架构，并通过代码实现将碎片化的想法串联成闭环。当整套逻辑链条趋于顺畅后，不仅第二次作业的完成水到渠成，再次回顾首题时，也能以更清晰的视角发现并修正此前的思路偏差。整体而言，这样的题目设计既给予了思维探索的空间，又通过适度的难度梯度引导认知逐步深化，让我在渐进式的思考中实现了从困惑到通透的转变。

*这两次题目级涉及到了以下知识点：
·里氏代换原则（LSP）：
代码中 Customer、Recipient、Sender 类继承自 People 类，这种继承关系符合 LSP
·开闭原则（OCP）
·合成复用原则（CRP）：
代码中多处使用组合关系，例如：
Customer 类包含 List，通过组合复用 Goods 类的功能。
Plane 类包含 List，表示航班与货物的关系。
Order 类关联 Sender、Recipient、Plane 对象，通过组合构建订单信息。
·继承和多态：Customer、Recipient、Sender 继承自 People 类，使用 extends 关键字实现代码复用。
·类的封装性：属性（如 name、phone）使用 private 或 protected 修饰，通过公共的 getter/setter 方法访问和修改（如 getName()、setPhone()）
·输入输出处理
·数据结构：使用LinkedList来管理请求队列

二、设计与分析：
1、题集八
（1）题目
一、计费重量规则
空运计费重量遵循「就高原则」，需对比货物实际重量与体积重量：
实际重量（Gross Weight）：货物本身的物理重量（单位：kg）。
体积重量（Volume Weight）：通过尺寸计算得出的虚拟重量，公式为：
体积重量（kg）= 长（cm）× 宽（cm）× 高（cm）÷ 6000
计费重量取值：两者中数值较高者作为最终计费依据。
二、基础运费计算逻辑
运费采用分段费率模式，根据计费重量（单位：kg）匹配对应单价：
重量 < 20kg：费率为 35 元 /kg
20kg ≤ 重量 < 50kg：费率为 30 元 /kg
50kg ≤ 重量 < 100kg：费率为 25 元 /kg
重量 ≥ 100kg：费率为 15 元 /kg
运费公式：
基础运费 = 计费重量 × 对应区间费率
三、业务场景与数据要求
模拟客户通过航空公司办理货运业务的全流程，需采集以下信息并生成报表：
（一）核心信息项
1、航班信息：航班号、起飞机场城市、降落机场城市、航班日期、最大载重量（kg）。
2、客户信息：姓名、电话号码。
3、货物信息：每件货物名称、包装尺寸（长 / 宽 / 高，单位：cm）、实际重量（kg）。
4、运送信息：发件人姓名 / 电话 / 地址、收件人姓名 / 电话 / 地址、所选航班号、订单日期。
5、支付方式：限定为「支付宝」或「微信支付」。
（二）输出要求
1、订单信息报表：展示订单基础信息（订单号、日期、支付方式）、发件人与收件人详情、所选航班关键信息、货物总计费重量。
2、货物明细报表：逐行列出每件货物的名称、计费重量、对应费率、单件运费，并汇总总运费。
3、如果订单中货物重量超过航班剩余载重量，程序输出The flight with flight number:航班号 has exceeded its load capacity and cannot carry the order. ，程序终止运行
四、数据交互流程
程序需通过键盘依次接收上述信息，按以下逻辑处理：
1、校验航班载重：若多件货物总计费重量超过航班最大载重量，需提示异常并终止流程。
2、单件货物计费：根据尺寸与重量独立计算每件货物的运费，支持批量处理。
3、报表格式化：以清晰的表格或分段结构呈现订单与货物明细，确保可读性。

（2）我的类图：

设计：
1、people类：抽象类（姓名、电话、地址）
2、Customer类：客户类继承people类（手机号、货物列表）
add方法：添加货物对象进入了列表
display方法：进行输出
3、Good类：货物类（编号、名字、宽、长、高、重量）
displaygrand方法：静态方法(便于在主类中直接调用），用于输出货物清单的背景信息，只需调 用一次
display方法：用于输出货物信息
price方法：用于计算此货物运费
comparaTo方法：比较应用于计算运费的重量并返回
Rate方法：返回费率
4、Plane类：航班类（航班号、出发时间、落地时间、日期、最大载重量、货物列表）、
add方法：添加货物对象进入了列表
check方法：判断货物总重量是否超出了飞机的最大载重量
allweight方法：计算已装入飞机的货物总重
price方法：计算总运费
display方法：进行输出信息
5、Order类：订单类（订单号、订单日期、支付方式）
displaypayment方法：输出支付方式与金额
display方法：输出信息
6、Sender类：发件人类，继承people类
display方法：进行输出信息
7、Recipient类：收件人类，继承people类
display方法：进行输出信息
（3）sourcemonitor图

分析：
文件名 Main.java
代码行数 535
语句数 120
分支语句占比 4.2%
方法调用语句数 52
含注释的代码行占比 3.0%
类和接口数 5
每个类的平均方法数 4.00
每个方法的平均语句数 4.15
最复杂方法的行号 451
最复杂方法的名称 Main.main ()
最大复杂度 6
最深代码块的行号 494
最大代码块深度 4
平均代码块深度 1.69
平均复杂度 1.28

*小结：第一次作业当时并没有做对，而是在第二次作业的代码的基础上，删去了一些方法而形成的代码

2、题集九
（1）题目：
一、计费重量的确定
空运以实际重量（GrossWeight）和体积重量（VolumeWeight）中的较
高者作为计费重量。
计算公式：
体积重量（kg）= 货物体积（长×宽×高，单位：厘米）÷6000
二、基础运费计算
1、费率（Rate）：航空公司或货代根据航线、货物类型、市场行情等制定（如CNY30/kg）。本次作业费率与货物类型有关，货物类型分为普通货物、危险货
物和加急货物三种，其费率分别为：
（1）普通货物
普通货物的费率（Rate）与重量相关，具体如下：
当重量 < 20 时，费率为 35 。
当 20 ≤ 重量 < 50 时，费率为 30 。
当 50 ≤ 重量 < 100 时，费率为 25 。
当重量 ≥ 100 时，费率为 15 。
（2）危险货物
危险货物的费率（Rate）依据重量不同而变化：
当重量 < 20 时，费率为 80 。
当 20 ≤ 重量 < 50 时，费率为 50 。
当 50 ≤ 重量 < 100 时，费率为 30 。
当重量 ≥ 100 时，费率为 20 。
（3）加急货物
加急货物的费率（Rate）按重量区间确定：
当重量 < 20 时，费率为 60 。
当 20 ≤ 重量 < 50 时，费率为 50 。
当 50 ≤ 重量 < 100 时，费率为 40 。
当重量 ≥ 100 时，费率为 30 。
计算公式：基础运费 = 计费重量 × 费率 × 折扣率其中，折扣率是指不同的用户类型针对每个订单的运费可以享受相应的折扣，在本题中，用户分为个人用户和集团用户，其中个人用户可享受订单运费的9折优惠，集团用户可享受订单运费的8折优惠。
三、题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：航空公司提供如下信息：
航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载重量）
2、客户填写货运订单并进行支付，需要提供如下信息：
客户信息（姓名，电话号码等）
货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
支付方式（支付宝支付、微信支付、现金支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独计费

（2）我的类图：

设计：
5、people类：抽象类（姓名、电话、地址）
6、Customer类：客户类继承people类（客户类型、手机号、货物列表）
Discount方法：判断客户类型返回折扣
add方法：添加货物对象进入了列表
display方法：进行输出
7、Good类：货物类（类型、编号、名字、宽、长、高、重量）
displaygrand方法：静态方法(便于在主类中直接调用），用于输出货物清单的背景信息，只需调 用一次
display方法：用于输出货物信息
price方法：用于计算此货物运费
comparaTo方法：比较应用于计算运费的重量并返回
Judgement方法：判断货物类型返回1、2、3
Rate方法：根据货物类型返回费率
8、Plane类：航班类（航班号、出发时间、落地时间、日期、最大载重量、货物列表）
add方法：添加货物对象进入了列表
check方法：判断货物总重量是否超出了飞机的最大载重量
allweight方法：计算已装入飞机的货物总重
price方法：计算总运费
display方法：进行输出信息
5、Order类：订单类（订单号、订单日期、支付方式）
Judgement方法：判断支付方式返回1、2、3
displaypayment方法：根据客户选的支付方式进行输出支付方式与金额
display方法：输出信息
6、Sender类：发件人类，继承people类
display方法：进行输出信息
7、Recipient类：收件人类，继承people类
display方法：进行输出信息

（3）sourcemonitor图

分析：
文件名 Main.java
代码行数 627
语句数 89
分支语句占比 7.9%
方法调用语句数 16
含注释的代码行占比 0.6%
类和接口数 4
每个类的平均方法数 5.25
每个方法的平均语句数 2.29
最复杂方法的行号 32
最复杂方法的名称 Customer.discount ()
最大复杂度 4
最深代码块的行号 36
最大代码块深度 3
平均代码块深度 1.48
平均复杂度 1.26

*小结：这次题目改正了一些逻辑错误后也并没有做对，是后面经过室友帮助，修改了格式错误后才答案正确。也是这个过程获得了踩坑心得。

三、踩坑心得
1、字符串值比较必须使用 equals 方法
在 Java 中，使用双等号（==）比较字符串时，实际比较的是两个字符串对象的内存地址（引用），而非字符串内容。若需比较字符串内容是否相同，必须使用equals()方法或其变体。
2、使用制表符替代空格缩进
代码中需要输出 4 个空格的缩进时，应统一使用制表符（\t）代替空格。制表符具有更好的可移植性，且能避免不同编辑器因空格显示不一致导致的格式问题。

四、改进建议
1、包名与类名规范 变量命名优化
2、航班超重逻辑改进
问题：当前 check() 方法在超重时直接移除最后一件货物，但未提示用户具体哪件货物被移除，且循 环添加货物时可能遗漏校验。
建议：
在添加每件货物前校验，而非循环结束后统一校验。
超重时返回明确错误信息，包含货物编号或名称。
3、避免魔法值（Magic Number）
问题：代码中直接使用 6000.0、20、35 等硬编码数值，难以维护。
建议：定义常量
4、引入策略模式（费率计算）
问题：Rate() 方法中硬编码费率规则，若规则变更需修改代码。
建议：定义费率计算接口 RateCalculator，不同规则实现该接口，通过策略模式动态切换
5、分离职责（订单与支付逻辑）
问题：Order 类同时处理订单信息和支付逻辑（displaypayment），违反单一职责原则。
建议：将支付逻辑抽取为独立类 PaymentService

五、总结
这次作业我明显感受到了自己的进步：从面对复杂编程题时的无从下手，到能梳理出清晰的思路并形成代码逻辑闭环，尤其是对单一职责原则的运用更加熟练，将订单、航班等功能拆分到独立类中，让代码结构更清晰。
不过，向 AI 请教改进建议时，也被他狠狠的“批评”了一番,暴露了不少问题：代码中存在硬编码 “魔法值”、缺乏必要注释、参数校验不完善，部分方法命名表意模糊，异常处理和边界条件考虑不足。这些问题反映出我在代码健壮性和可维护性上的欠缺。
未来我会重点优化代码结构、补充注释、完善校验逻辑、对每一处细节都进行反复打磨。