关于PTA航空货运管理系统题目的总结

目录

• 引言
• 设计与分析
• 踩坑心得
• 改进建议
• 总结
  

一、引言

1. 背景信息

航空货运管理系统是什么？

航空货运管理系统是航空物流数字化转型的核心基础设施，其发展源于全球贸易深化、跨境电商爆发及行业竞争加剧，传统手工操作难以满足高时效、复杂化的运输需求。技术层面，物联网、大数据、区块链等推动货物实时追踪、智能调度与跨境协同，云计算则降低系统部署门槛。系统核心目标涵盖效率提升（如自动订舱、差错减少）、成本优化（动态定价、舱位利用）、服务升级（客户自助平台、定制方案）及合规管理（海关对接、危险品校验），集成订单管理、运输执行、仓储清关等模块。当前面临系统孤岛、技术投入差异、跨境监管复杂及实时性要求高等挑战，未来将向智能化（AI客服、无人机应用）、绿色化（碳足迹计算）、全球化协同（区块链网络）、低代码平台及空铁联运融合方向发展，典型如IATA Cargo 2000与DHL MyChain等系统已实现全链条可视化管理。

注：本次作业主要考虑货物重量/体积。

2. 题目信息

本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场所在城市，航班降落机场所在城市，航班日期，航班最大载重量）
客户填写货运订单并进行支付，需要提供如下信息：

1.客户信息（姓名，电话号码等）

2.货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）

3.运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选航班号，订单日期）

4.支付方式（支付宝支付、微信支付）

如果订单中货物重量超过航班剩余载重量，程序输出The flight with flight number:航班号 has exceeded its load capacity and cannot carry the order.程序终止运行。
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独计费。

程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信息报表及货物明细报表。
输入格式：

输出格式：

二、设计与分析

1. 过程分析

（1）处理逻辑

1. 首先按照根据题目所给的信息，按照顺序依次地读取对应数据，对于[ ]内的数据使用循环读取，然后顺序完成全部数据的读取。
2. 然后根据读入的数据，先计算总共的货物的重量，如果订单的总重量超过了剩余重量，那么，就输出 The flight with flight number:航班号 has exceeded its load capacity and cannot carry the order.程序终止运行(错误输出)，如果订单中货物重量没有超过航班剩余载重量，继续计算费率，对于每一个商品如果要得到它的费率，首先要得到计费重量，即：空运以实际重量（GrossWeight）和体积重量（VolumeWeight）中的较高者作为计费重量。
3. 在完成了各个商品的费率计算之后，可以根据商品的重量计算它的运费。最后将所有的商品的运费计算总运费。
4. 在第二次作业中，费率与货物类型有关，货物类型分为普通货物、危险货物和加急货物三种，同时还增加了折扣率的概念，与用户类型针对每个订单的运费可以享受相应的折扣，还有支付方式的增加（支付宝支付、微信支付、现金支付）。
5. 新增的三种类都要将父类进行泛化，三个子类分别继承他们的分类，来完成各自的功能。

（2）类设计
为了完成这个航空货运系统，我设计了这些类：
OrderItem类 Order类 Good类 Customer类 Flight类 Payment类 OrderManager类 Controller类
用来处理整个逻辑，在第二次作业中，加入了对于Good类、Customer类、Payment类泛化，用几个对应的子类去继承。

2. 难点解决

（1）读入数据

使用 Scanner 逐行读取用户输入，输入字段较多（客户信息、货物详情、航班信息等）。
Scanner 的nextInt()/nextDouble() 与 nextLine() 混用导致的换行符问题，需要注意换行符处理（如 input.nextLine() 消耗多余换行符）。
如果输入非预期类型（如输入字母代替数字），就会导致整个程序读入数据报错，类型不符。

（2）类设计难点分析

第一次作业

1. WechatPay类

• 作用：实现微信支付功能，通过重写 Payment 抽象类的 pay(double amount) 方法，完成微信支付逻辑。
• 关系：继承自 Payment 抽象类，是支付方式的具体实现类。

2. AliPay类

• 作用：实现支付宝支付功能，重写 Payment 的 pay(double amount) 方法，完成支付宝支付逻辑。
• 关系：继承自 Payment 抽象类，与 WechatPay 并列，同为支付方式的具体实现。

3. Payment类

• 作用：抽象类，定义支付行为的接口 pay(double amount)，规范所有支付方式的核心操作。
• 关系：被 WechatPay、AliPay 继承，为具体支付方式提供抽象模板。

4. Controller类

• 作用：系统控制层，接收外部请求（如用户输入），协调 OrderManager 处理业务逻辑（如添加新订单）。
• 关系：
  • 依赖 OrderManager，通过构造函数 Controller(OrderManager orderManager) 注入实例。
  • 调用 OrderManager 的方法（如 addNewOrder(Order order)）完成订单管理操作。

5. OrderManager类

• 作用：订单管理核心类，维护订单列表（List<Order>），提供订单的增删改查等管理功能。
• 关系：聚合 Order 类，通过 List<Order> 存储多个订单实例；被 Controller 依赖，为其提供订单管理服务。

6. Customer类

• 作用：封装客户信息，包括客户ID（customerID）、姓名（name）、电话（phone）、地址（address）等，提供数据访问方法（如 getCustomerID()、setAddress()）。
• 关系：通过 customerID 与 Order 类关联，表明订单由特定客户创建。

7. Order类

• 作用：代表一个货运订单，包含订单ID（orderID）、客户ID（customerID）、订单项列表（list）、关联航班（Flight）、订单日期（orderDate）等信息，提供支付（pay(Payment payment)）等订单操作方法。
• 关系：
  • 聚合 OrderItem 类（List<OrderItem>），表示一个订单包含多个订单项。
  • 关联 Flight 类，通过 setFlight(Flight flight) 绑定运输航班。
  • 被 OrderManager 管理，存储于 OrderManager 的订单列表中。

8. OrderItem类

• 作用：关联订单与货物，记录订单项ID（orderItemID）和对应的货物（Good），可用于计算单个货物在订单中的信息（如重量）。
• 关系：包含 Good 类实例，作为 Order 类中订单项列表的元素（即被 Order 聚合）。

9. Good类

• 作用：描述货物属性，如名称（name）、重量（weight）、长度（length）、宽度（width）、高度（height），提供属性访问和修改方法（如 setWeight(int weight)）。
• 关系：被 OrderItem 包含，作为订单项的核心内容。

10. Flight类

• 作用：存储航班信息，包括航班ID（flightID）、出发地（departure）、目的地（destination）、航班日期（flightDate）、最大载重（maxWeight）等，提供信息访问方法（如 getDeparture()）。
• 关系：被 Order 类关联，一个订单对应一次航班运输，航班载重限制影响订单货物的合法性。

第二次作业

Customer类
作用：封装客户基本信息（ID、名称、联系方式等）。
关系：通过 customerID 关联 Order。
Good类
作用：表示货物属性（名称、重量、尺寸等）。
关系：被 OrderItem 包含。
Payment类
作用：处理订单支付逻辑（支付方式、金额、状态）。
关系：被 Order 调用，子类（如微信支付、支付宝）实现具体支付。

新增了工厂类（如CustomerFactory、GoodFactory）
作用：封装对象创建逻辑（如根据客户等级创建 Customer）。
关系：被 Controller 或 OrderManager 调用，提供实例化服务。

这些类的设计比较好得符合了：单一职责原则、里氏代换原则、开闭原则、合成复用原则、依赖倒转原则

三、踩坑心得

在本次的题目中，出现了许多的问题，也让我发现了许多的不足：

1. 类的数量方面

起初，题目中关于订单的处理方法不清楚，仅仅设计关联了Order类和Good类来处理商品增加的逻辑。但是，实际上这样的设计是不合理。因为这样设计会使得Good类和Order类之间的关系变模糊，然后会难以修改商品的属性，对于一个订单里面有多个商品的关系难以实现。此外，一开始我并不确定要设计几个类，只涉及了基本的Good类、Flight类、Customer类、Payment类。在设计在后期修改上，我在网上多方搜集资料，学习成熟项目的设计方法。新增加了Controller类（满足MVC）、OrderItem类、OrderManager类；
反思：以后要提前多了解有关题目的信息，比如在本题里面是：航空货运系统的背景知识，在实际应用的设计里面是如何设计的，要继续学习将复杂职责拆分，使得类功能明晰且内聚，加强面向对象原则的学习。

2. 类间关系

在这次题目里面出现了许多的类，设计的过程中，我学习如何设计它们之间的关系，对于继承、依赖、组合和聚合等，具体来说：主要是OrderItem类关联Good类，Order类组合OrderItem类（合成复用）、Order类关联Flight类、Controller类关联Order Manager类和Order类、Customer类直接被Main类调用。
虽然说起来简单，但是实际在设计的时候，还是出现了许多的问题，在整个题目中：我认为订单和商品和订单明细的关系是最难理解的，一个订单对应着多个订单明细，而每一个订单明细又对应着每一个商品。

四、改进建议

第一次题目：

计算价格分析

属性

• 货物重量weight和货物数量num：类型为int是商品计算价格的核心属性

方法

在各个类里面调用方法的关系
Order.calculateTotalCost() → OrderItem.getWeight() → Good.getRealWeight() → Order.getRate()

第二次题目：

迭代信息

对于Good类、Customer类、Payment类泛化，用几个对应的子类去继承，用于处理第二次题目里面的对于不同的客户取不同的折扣率，对于不同的商品类型采取不同的计算费率的方式，然后选择不同的支付方式。

类设计思路

代码中通过三个工厂类（CustomerFactory、GoodFactory、PaymentFactory）实现了对象创建与使用的分离，符合工厂模式的核心思想。系统更具灵活性和可维护性，尤其适合需要根据不同条件创建不同类型对象的场景。在第二题里就使用工厂来根据读入的信息选择创建怎样的子类，配合题目要求。

SourceMonintr分析

主要参数：
Classes and Interfaces：类和接口总数（5），反映代码的封装层次。
Methods per Class：平均每个类的方法数（7.20），表明类的功能丰富度，但过高可能影响单一职责。
Average Statements per Method：每个方法平均语句数（4.44），说明方法逻辑的简洁性。
Line Number of Most Complex Method：最复杂方法的行号（254），定位到 GoodFactory.createGood() 方法。
Maximum Complexity：最大复杂度（7），衡量该方法逻辑的复杂程度（如分支、循环嵌套等）。

雷达图

% Comments（注释百分比）：数值较低，表明在我的代码中注释占比少，影响代码可读性与维护性。
Methods/Class（每个类的方法数）：若数值偏高，类的职责可能不够单一，在这一点上还需要改进，（实际上我已经尽量将类给拆开了，可能是因为水平不行）
Avg Stmts/Method（每个方法的平均语句数）：反映方法的简洁性，数值越高，方法可能越冗长，逻辑越复杂。
Max Complexity（最大复杂度）：表示代码中最复杂方法的复杂度，数值为7说明存在逻辑复杂的地方
Max Depth（最大深度）：码块嵌套的最大层数为，深度大则逻辑嵌套深，增加理解与维护难度。
Avg Depth（平均深度）：体现代码块嵌套的平均复杂程度，数值越高，整体代码逻辑越复杂。
Avg Complexity（平均复杂度）：所有方法复杂度的平均值，反映代码整体逻辑复杂度，数值高则整体维护难度大。

除了注释的比例比较低，其余的要求都基本满足雷达图的要求。

柱状图

横轴和纵轴反映了我的代码的嵌套层数和深度，在这一方面表现得比较好，大多数的代码都在2和3左右的嵌套层数

五、总结

学习收获

1. 进一步理解单一职责原则，如 Good 类专注货物属性与计费重量计算；开闭原则，通过工厂模式扩展新客户 货物类型时不修改现有代码。
2. 提升了类间关系设计能力，合理运用继承（Customer 子类）、组合（Order 包含 OrderItem）等。
3. 要增加注释说明关键逻辑（如费率计算规则），规范命名，提升代码可维护性。
4. 使用 Scanner 读取用户输入，需注意处理换行符（如 input.nextLine() 消耗多余换行），避免输入错位。
5. 学会根据错误信息定位问题，通过阅读代码、检查类定义与调用处参数，快速修复问题，提升调试效率。

少许建议

针对初学者常见的类设计模糊、模式应用生硬、输入处理不当等问题，通过场景化案例、可视化工具和分阶段练习帮助学生建立清晰的编程思维。