航空管理系统总结

一、前言

本题要求对航空货运管理系统进行类设计，运用继承与多态知识。输入时需按特定顺序录入客户、货物、航班、订单相关信息。客户分个人与企业，货物有普通、加急、危险等类型。

若订单货物超重，程序输出航班超载提示并终止；若航班能承接，要输出客户订单详情、支付金额及货物明细，且实型数保留一位小数。

该题难度适中，重点考查对面向对象特性的掌握，以及数据处理和业务逻辑实现能力，需精准把控各类信息的交互与处理。

二.设计分析：

第一次

代码结构与类设计

  1. Rate类
    • 用于根据货物重量确定计费费率。
    • 构造函数根据不同重量区间设置rate成员变量的值。但存在不足，当满足多个if条件时，会重复赋值，应使用if - else if结构优化，以避免不必要计算。
  2. Customer类
    • 封装客户信息，包含客户编号、姓名、电话和地址。
    • 通过构造函数初始化成员变量，设计简单直接，符合数据封装思想。
  3. Goods类
    • 描述货物信息，有货物编号、名称、长宽高和重量等属性。
    • setweight方法根据体积重量（长宽高之积除以 6000 ）和实际重量对比，取较大值更新货物重量，考虑了航空货运中体积重量计费规则。
  4. Flight类
    • 记录航班信息，如航班号、起降机场、日期、最大载重量和当前载重量。
    • canCarry方法用于判断航班能否承载订单重量，addLoad方法用于更新航班当前载重量，功能明确，保证了航班载重量管理逻辑的正确性。
  5. Order类
    • 整合订单相关信息，包括订单编号、日期、收发件人信息及货物列表。
    • 构造函数计算订单总重量，calculateFee方法遍历货物列表，结合Rate类计算订单总运费，逻辑清晰，实现了订单核心业务计算。
  6. Main类
    • main方法是程序入口，负责从控制台读取各类信息，创建相关对象，检查航班载重，计算费用并输出结果。代码流程与题目输入输出要求一致，但在输入校验方面存在不足，未对输入数据的合法性（如日期格式、重量非负等 ）进行严格检查。

代码优缺点总结

  • 优点
    • 类的职责划分较明确，每个类专注于特定功能，符合面向对象设计原则，便于理解和维护。
    • 基本实现了航空货运管理系统的业务逻辑，从数据录入到计算和输出，流程连贯。
  • 缺点
    • 输入校验缺失，可能导致程序在非法输入下出现异常。
    • Rate类的计费费率计算逻辑可优化，避免重复赋值。
    • 代码中硬编码了一些提示信息（如 “微信支付金额” ），缺乏灵活性，未根据实际支付方式输出。

改进建议

  • 增加输入数据的合法性校验，例如使用正则表达式检查日期格式，确保重量等数值非负。
  • 将Rate类的if语句改为if - else if结构。
  • 引入枚举类型表示支付方式，根据实际支付方式输出对应的支付金额提示信息。

第二次

从提供的分析图和数据来看，该飞机货物系统的 Main.java 文件具有以下特点：

1. 低复杂度设计

  • 最大复杂度为 0：表明代码中没有方法被认定为复杂（可能使用了简单的线性逻辑或基本条件判断）。
  • 分支语句占比仅 1.6%：说明代码中条件判断（如 if-else、switch）较少，逻辑可能较为直接。
  • 方法调用仅 4 条：显示代码可能以顺序执行为主，缺乏方法间的调用层次。

2. 代码结构与规模

  • 421 行代码包含 61 条语句：平均每行代码包含约 0.14 条语句，可能存在较多空行或注释（但注释占比仅 3.8%，说明空行较多）。
  • 4 个类和接口：结构相对简单，但每个类平均有 7.75 个方法，可能存在类职责不明确的问题。
  • 平均每个方法的语句数为 0：这一数据可能存在统计误差，实际应结合代码确认。

3. 注释与可读性

  • 注释覆盖率低（3.8%）：代码可能缺乏必要的文档，对后续维护和理解造成困难。
  • 低复杂度与低注释的矛盾：虽然代码简单，但缺乏注释可能导致难以快速理解业务逻辑（如飞机货物管理的规则）。

4. 潜在问题

  • 深度分布不均：柱状图显示大部分语句集中在深度 0 和 1，说明代码可能缺乏分层设计，导致逻辑扁平化。
  • 方法调用过少：可能导致代码重复度高，缺乏模块化。
  • 类方法数量多：每个类平均 7.75 个方法，可能违反单一职责原则，增加维护成本。

改进建议

  1. 优化代码结构：
    • 将逻辑拆分为更小的方法，提高复用性。
    • 使用设计模式（如策略模式、工厂模式）处理复杂业务规则。
  2. 提高可读性：
    • 增加必要的注释，尤其是关键业务逻辑和算法。
    • 遵循命名规范，使用有意义的类名和方法名。
  3. 平衡复杂度：
    • 适当增加方法调用层次，减少深度为 0 的长方法。
    • 使用异常处理替代大量条件判断。
  4. 测试与验证：
    • 补充单元测试，确保代码在各种场景下的正确性。
    • 使用静态代码分析工具（如 SonarQube）检测潜在问题。

总结

该代码整体复杂度较低，但存在结构不合理、注释不足等问题。对于飞机货物系统这类可能涉及复杂业务规则的应用，建议在保持低复杂度的同时，通过模块化和文档化提高代码的可维护性和可扩展性。

三、问题

总体逻辑虽不复杂，但在处理众多变量时，理清它们之间的关系颇具挑战。为了更好地把控全局，我设计了一个中控类。该类就像是整个系统的大脑，统筹协调各个部分的运作。

在这个航空货运管理系统中，客户信息、货物信息、航班信息以及订单信息纷杂繁多。中控类的出现，旨在将这些分散的信息进行整合与管理。它负责接收从不同渠道输入的各类数据，然后依据既定规则，对这些数据进行梳理与关联。

比如，在处理订单时，中控类会从客户类获取客户相关信息，从货物类收集货物详情，从航班类了解航班的承载能力等信息，再将这些信息综合起来，判断订单是否能够顺利执行。如果遇到航班载重量不足的情况，中控类会及时发出提示，终止程序后续操作；若一切正常，则会指挥系统继续进行费用计算、信息输出等步骤。

然而，即便有了中控类的总体控制，目前仍出现了一些问题。可能是在信息传递过程中，部分变量的赋值或调用出现了偏差，导致中控类接收到的数据不准确，进而影响了后续的判断与操作。也有可能是中控类与其他类之间的接口设计不够完善，使得数据交互时出现了冲突或遗漏。这些问题都需要进一步深入排查代码细节，仔细检查变量的定义、赋值以及方法的调用逻辑，通过逐步调试来定位并解决，以确保整个航空货运管理系统能够稳定、准确地运行。

四、总结

在设计分析中，首次设计的代码各有优劣。类设计上职责相对明确，实现了业务逻辑，但存在输入校验缺失、计费逻辑待优化、提示信息硬编码等问题。改进建议包括完善输入校验、优化代码逻辑及引入枚举处理支付方式。第二次从代码度量角度分析，发现其虽复杂度低，但存在结构不合理（如深度分布不均、方法调用少、类方法多）、注释不足等问题。改进方向为优化结构、提升可读性、平衡复杂度并加强测试验证。

在系统实现中，为应对变量关系梳理难题，引入中控类统筹协调。但目前中控类运行仍存问题，可能源于信息传递偏差或接口设计缺陷。后续需深入排查代码细节，调试解决，保障系统稳定准确运行。

总体而言，航空货运管理系统在设计与实现过程中既有成果，也暴露出诸多问题，需通过针对性改进措施不断完善，以满足实际应用需求。

posted @ 2025-05-25 18:44  章羽  阅读(30)  评论(0)    收藏  举报