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

一、前言

这次航空货运管理系统的作业重点在于其中的类设计，要求符合面向对象程序设计原则，题目的核心逻辑较为简单，
没有上次电梯题目难，但是其用到的知识点却非常多，总体上比较简单，只要合理的设计类与类之间的关系，便可以很快完成。

二、设计与分析

第一次作业分析

题目：

一、空运以实际重量（Gross Weight）和体积重量（Volume Weight）中的较高者作为计费重量。
计算公式：
体积重量（kg） = 货物体积（长×宽×高，单位：厘米）÷ 6000
示例：
若货物实际重量为 80kg，体积为 120cm×80cm×60cm，则：
体积重量 = (120×80×60) ÷ 6000 = 96kg
计费重量取 96kg（因 96kg > 80kg）。
二、基础运费计算
费率（Rate）：航空公司或货代根据航线、货物类型、市场行情等制定（如
CNY 30/kg）。本次作业费率采用分段计算方式：

公式：基础运费 = 计费重量 × 费率
三、题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场所在城市，航班降落机场所在城市，航班
日期，航班最大载重量）
客户填写货运订单并进行支付，需要提供如下信息：
 客户信息（姓名，电话号码等）
 货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
 运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
 支付方式（支付宝支付、微信支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独
计费。
程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信
息报表及货物明细报表。
四、题目要求
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开
闭原则以及合成复用原则，除需要在PTA平台提交源码外，还需要在超星平台
提交本次作业最终得分源码（首次提交最高分源码）的类图，评判标准为：
基础得分：PTA实际得分
设计因素：单一职责原则（40%）、里氏代换原则（20%）、开闭原则（20%）、
合成复用原则（20%）

1)类设计图：

2)源码分析：

1.数据模型类
Customer 类：存储客户基本信息（ID、姓名、电话、地址）
Goods 类：表示货物，计算实际重量（实重和体积重取最大值）
Flight 类：表示航班信息，包含最大载重限制
Order 类：表示订单，关联客户、航班和多个货物，计算总费用
2. 接口与实现
Flightgoodsfee 接口：定义计算货物费用的方法
Flightgoodsfeejisua 类：实现阶梯式计费规则（根据重量不同收取不同费率）
3. 支付系统
Payment 抽象类：定义支付行为
WeChatPay 和 AliPay 类：实现具体支付方式
4. 主程序流程
从控制台读取客户信息、多个货物信息、航班信息和订单信息，计算总重量，检查航班载重限制，生成订单并打印详细信息

3)SourceMontor分析

分支语句占比（Percent Branch Statements）：2.9% ，分支逻辑（如 if - else 等）占比较低。
方法调用语句数（Method Call Statements）：8 条，方法间调用不算频繁。
注释行占比（Percent Lines with Comments）：0.0% ，无注释，不利于代码可读性和维护。
类和接口数量（Classes and Interfaces）：7 个，结构有一定复杂度。
平均每个类的方法数（Methods per Class）：14.71 ，类中方法较多，可能存在职责不够单一问题。
平均每个方法的语句数（Average Statements per Method）：1.02 ，方法较为简短。
最复杂方法的行号（Line Number of Most Complex Method）：186 行。
最复杂方法的名称（Name of Most Complex Method）：Flightaoodsfeeiiusa.canCarry() 。
由此看出对于类和接口数量有 7 个且方法较多的情况，提取公共类、接口来简化结构，提高代码复用性。
虽然分支语句占比仅 2.9% ，但仍需检查分支条件是否合理，避免不必要的嵌套，减少代码冗余和潜在错误。
在Flightaoodsfeeiiusa.canCarry() 方法，分析其复杂度高的原因，通过提取子逻辑、减少循环嵌套等方式优化，提升运行效率。
且由于类的设计的不合理,导致代码的篇幅较长,类的数量较多。
总结：
这是第一次在没有类图的情况下完成类与类关系的题目，所以类与类之间的关系设计的不是十分合理，导致代码的篇幅较长,类的数量较多，
有了这次的经验后，以后这类题目可以得心应手了。
分享心得：
记第一次电梯题目后，我认真看题目和分析题目要求，但是我仍然有一个小问题，
标点符号错误，导致我找了半天才发现问题所在，因此以后要认真看输出。

第二次作业分析

题目：

某航空公司“航空货运管理系统”中的空运费的计算涉及多个因素，通常包
括货物重量/体积、运输距离、附加费用、货物类型、客户类型以及市场供需等。
本次作业主要考虑货物重量/体积，以下是具体的计算方式和关键要点：
一、计费重量的确定
空运以实际重量（GrossWeight）和体积重量（VolumeWeight）中的较
高者作为计费重量。
计算公式：
体积重量（kg）= 货物体积（长×宽×高，单位：厘米）÷6000
示例：
若货物实际重量为80kg，体积为120cm×80cm×60cm，则：
体积重量 =(120×80×60)÷6000=96kg
计费重量取96kg（因96kg>80kg）。
二、基础运费计算
1
费率（Rate）：航空公司或货代根据航线、货物类型、市场行情等制定（如
CNY30/kg）。本次作业费率与货物类型有关，货物类型分为普通货物、危险货
物和加急货物三种，其费率分别为：

计算公式：基础运费 = 计费重量 × 费率 × 折扣率
其中，折扣率是指不同的用户类型针对每个订单的运费可以享受相应的折扣，
在本题中，用户分为个人用户和集团用户，其中个人用户可享受订单运费的9
折优惠，集团用户可享受订单运费的8折优惠。
三、题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载
重量）
2
客户填写货运订单并进行支付，需要提供如下信息：
 客户信息（姓名，电话号码等）
 货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
 运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
 支付方式（支付宝支付、微信支付、现金支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独
计费。
程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信
息报表及货物明细报表。
四、题目要求
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开
闭原则以及合成复用原则、依赖倒转原则，除需要在PTA平台提交源码外，还
需要在超星平台提交本次作业最终得分源码（首次提交最高分源码）的类图，
评判标准为：
基础得分：PTA实际得分
设计因素：单一职责原则（20%）、里氏代换原则（20%）、开闭原则（20%）、
合成复用原则（20%）、依赖倒转原则（20%）。

1)类设计图：

2)源码分析：

1.数据模型类
Customer 类：存储客户基本信息（ID、姓名、电话、地址）
Goods 类：表示货物，计算实际重量（实重和体积重取最大值）
Flight 类：表示航班信息，包含最大载重限制
Order 类：表示订单，关联客户、航班和多个货物，计算总费用
2. 接口与实现
Flightgoodsfee 接口：定义计算货物费用的方法
Flightgoodsfeejisua 类：实现阶梯式计费规则（根据重量不同收取不同费率）
3. 支付系统
Payment 抽象类：定义支付行为
WeChatPay，AliPay 和 Cash 类：实现具体支付方式
4. 主程序流程
从控制台读取客户信息、多个货物信息、航班信息和订单信息，计算总重量，检查航班载重限制，生成订单并打印详细

3)SourceMontor分析：

分支语句占比（Percent Branch Statements）：8.6%
方法调用语句数（Method Call Statements）：15 条，说明方法间存在一定的调用关系。
注释行占比（Percent Lines with Comments）：0.0% ，完全没有注释，这对代码的可读性和后期维护极为不利。
类和接口数量（Classes and Interfaces）：7 个，数量不算少，且平均每个类的方法数（Methods per Class）为 15.71 ，表明类的功能可能较为复杂、不够单一。
平均每个方法的语句数（Average Statements per Method）：1.33 ，方法相对简短，但结合类的方法数量多，可能存在方法功能过于碎片化的问题。
最复杂方法的行号（Line Number of Most Complex Method）：205 行，对应方法 Flightaoodsfeeiiusa.canCarry() ，此方法复杂度较高，可能存在逻辑过于复杂的问题。
由此看出代码中Flightaoodsfeeiiusa.canCarry() ，此方法复杂度较高，应该换种计费方法
且由于类的设计的不合理,导致代码的篇幅较长,类的数量较多。
总结：
有了第一次的经验后，明显比第一次更加容易上手，并且类与类之间的设计也十分合理但是其复杂度还是比较高，
后续我也会慢慢的修改，修改这种习惯。
分享心得：
有了第一次的教训后，然后发现还是有个问题，就是不小心多打了个空格，这种问题对我来说好容易发现，
虽然说这次及时发现，但是以后还是要慢慢打输出代码。

三.踩坑心得
由于是第一次自己设计类与类之间的关系，所以第一次类与类之间的关系，设计的不是十分合理，
但是经过这次后，以后的类与类之间的关系会设计的比较合理。

通过这些提交记录，就可以看出我一直再找一个错误，结果是标点符号错误，导致我找了半天才发现问题所在，因此以后要认真看输出。

四.改进建议

消除代码冗杂
将Wechat、Ali、Cash中的重复代码移至父类Payment
新建Person类，将Customer、Sender、Receiver 中的公共属性可放至Person
代码中应该尽量写注释,增强代码的可读性.
针对费率的计算,可以采用策略模式来减少if-else的使用
五.总结

通过这两次编程实践，我对面向对象程序设计原则有了更透彻的认知。将这些原则运用到航空货运管理系统的开发中后，系统逻辑变得更加清晰，代码结构也更有条理，这为系统后续的功能扩展奠定了坚实基础。此外，此次题目集新增的抽象类与接口设计，在众多类的管理方面发挥了关键作用，显著提升了代码的可维护性与可复用性。

这两次作业也让我意识到自身存在的诸多问题。例如，初期由于对接口的设计意义理解不深入，导致系统的初始设计逻辑出现较大偏差。但在不断调试和优化代码的过程中，我逐渐领悟到接口在解耦模块、规范行为契约方面的核心价值，这一过程极大地锻炼了我的编程思维，也让我的问题分析与架构设计能力有了实质性提升。

未来，我将继续深化对面向对象设计原则的应用，尤其是加强对抽象层设计与接口规范的实践，确保在复杂系统开发中能够更合理地划分职责、降低耦合度，进一步提升代码质量与开发效率。