航空管理系统题目集总结

1. 前言
   PTA 阶段性迭代作业已完成，现依据规范要求撰写总结性博文。着重剖析两次题目集末尾涉及的航空货运管理系统题目项。
   题目集 08 的核心任务是类设计工作，涉及的知识点从宏观层面划分为面向对象编程，细分包括类的定义与封装机制、构造方法及其重载技术、访问修饰符（private、public 等）的运用规则，特别包含数组列表 ArrayList 的使用实例，该数据结构主要承担货物订单信息的存储功能。
   题目集 09 涵盖前次全部知识点，新增继承与多态的概念及应用实例、方法重写技术的实践运用。值得注意的是，该题目允许通过接口方式完成费率计算工作，虽非强制要求，但为实现途径之一。
   纵观整个练习阶段，编程训练重心集中于 Java 语言核心的面向对象特性掌握，编程实践中亦涉及面向对象七大设计原则，其中单一职责原则与开闭原则表现尤为突出。
   难度层面分析
   相较于前一阶段的单部电梯调度程序，本次航空货运管理系统难度较低，原因如下：
   系统逻辑复杂度较电梯程序简化，按作业说明逐步编写即可完成
   可能因笔者对电梯程序中队列概念理解深度不足
   整体而言，本次系统设计未涉及复杂算法逻辑要素。
   题量维度分析
   本阶段两次题目集设置与以往一致，每次包含三道题目项，前两道相对容易，使学习者可将更多精力集中于最后一道题目的深入思考与实践解答。
2. 设计与分析
   第一次航空货运管理系统
   某航空公司 “航空货运管理系统” 中空运费计算受多因素影响，包括货物重量 / 体积、运输距离、附加费用、货物类型、客户类型及市场供需等。空运计费重量以实际重量（Gross Weight）和体积重量（Volume Weight）中的较大值为准，具体计算公式：
   体积重量（kg）= 货物体积（长 × 宽 × 高，单位：厘米）÷ 6000
   本次题目模拟客户至该航空公司办理货运业务流程，航空公司提供的信息包括：
   航班信息（航班号、起飞机场所在城市、降落机场所在城市、航班日期、最大载重量）
   客户填写货运订单并完成支付时需提供：
   客户信息（姓名、电话号码等）
   货物信息（货物名称、包装长度、宽度、高度尺寸及重量等）
   运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选航班号，订单日期）
   支付方式（支付宝支付、微信支付）
   一个货运订单可包含多件货物，每件货物需根据重量及费率单独计算费用。
   设计说明
   定义CalculatorRate接口用于实现费率计算功能，订单具备费率计算能力，采用接口设计模式
   设计基础类结构，包括货物类（Cargo）、订单类（Order）、客户类（Customer）、航班类（Flight）等
   枚举类型在系统中并非必需组件，可采用字符串类型替代实现相应功能
   以下是我的类图分析
   

复杂度分析

六维雷达图分析结果显示，本次航班程序复杂度较低，分支语句在整体代码中占比仅 3.7%，显著低于上一阶段电梯调度程序同类指标，程序最大复杂度指标维持较小数值，因题目本身逻辑设计简洁
柱状图分析表明，main 函数中存在较多输入语句，导致函数调用深度显著增加
程序注释量占比仅 6%，暴露代码注释习惯不足，造成维护问题，初次编码时清晰的方法逻辑一周后因缺乏注释难以理解，影响代码可读性和可维护性
核心功能实现中，负责重量计算的两个方法承担关键逻辑，通过比较实际重量与体积重量数值大小，确定计费重量并完成费用计算，实现订单一次性处理
编码过程中，因变量命名缺乏清晰语义区分，导致两种重量数据频繁混淆，引发输出结果为空或重量数据不匹配等问题，经长时间调试分析，即便在变量名前添加语义前缀仍存在理解障碍，最终通过细化注释和分步调试完成功能实现
第二次航空货运管理系统
第二次航空货运管理系统作业是在第一次作业类设计基础上的迭代开发，技术实现新增继承与多态应用场景。因第一次作业已采用接口实现费率计算功能，实际已隐性应用多态特性，两次作业在核心设计思想上具有较强延续性，具体迭代工作量相对有限。
主要扩展内容
货物类型体系扩展：在第一次作业单一普通货物类型基础上，新增加急货物和危险货物两类特殊货物，不同类型货物对应不同费率计算逻辑，依然采用接口机制实现费率计算功能的多态性
运费折扣机制引入：在基础运费计算模型中新增折扣率参数，折扣率应用规则基于用户类型差异化设置：
个人用户可享受订单运费的 9 折优惠
集团用户可享受订单运费的 8 折优惠
该机制通过用户类型的继承体系与运费计算方法的重写，实现多态特性在业务逻辑中的具体应用。
类图分析：

本次迭代通过继承机制扩展货物类型业务场景，通过多态机制实现差异化费率计算与折扣策略，既保持第一次作业的接口设计框架，又实现业务逻辑的增量扩展，体现面向对象设计的开闭原则。
复杂度分析

经 SourceMonitor 工具分析显示，该类存在与首次作业相同的代码质量问题：
方法平均复杂度指标偏高
代码注释率维持较低水平，反映代码可维护性不足
main 方法内语句数量过多，可能违反面向对象设计中的单一职责原则，一旦出现逻辑错误，导致复杂调试与维护问题
分析数据表明深度 2 代码在整体结构中占比较高，反映代码中嵌套语句使用频率过高，源码中存在大量 if-else 条件语句嵌套应用，部分条件分支中还嵌入 for 循环结构，多层嵌套代码结构增加逻辑理解难度，对代码可测试性和可扩展性产生负面影响
从软件设计规范角度审视，需对 Main 类代码结构进行重构优化，针对方法职责单一性不足和嵌套层级过深问题，通过模块化设计将复杂逻辑拆分为独立方法，同时强化代码注释规范，提升系统整体可维护性
3. 实践踩坑心得
强化审题严谨性
两次作业中，视觉疏忽导致低级错误突出，如将支付方式命名 “APLiPay” 误读为 “ApliPay”，“Wechat” 误写为 “WeChat”，此类因审题不细致引发的语义错误，在调试过程中耗费大量时间定位，需通过强化文本比对习惯加以规避。
设计合理性验证优先
第二次迭代开发中，初始方案将支付方式逻辑嵌入客户类，虽直觉具备合理性，但实际编码时无法满足业务需求，40 分钟后推翻重做，表明编码前需通过类图或伪代码进行设计验证，避免因架构缺陷导致返工。
关注格式细节处理
首次作业中，测试用例匹配失败的典型场景包括：
输出空格与制表符混淆（通过样例比对发现实际应为制表符）
中英文标点符号混用（如中文冒号导致解析错误）
提示语句文本严格匹配问题（如 “The flight with flight number: 航班号...” 中 “航班号” 需替换为实际编号，而非字面字符串）
输出格式规范把控
除 “-” 符号可直接复制外，格式陷阱主要集中于：
空白符类型（空格与制表符需通过样例测试确认）
异常提示语句的精确性（如超载提示需严格按要求拼接航班号变量，而非固定文本），此类问题需通过逐字符比对样例输出解决
支付逻辑演进适配
首次作业因未明确支付方式输入要求，导致微信支付逻辑实现受阻；第二次作业通过明确输入规范，该问题得以解决，表明需求理解需随迭代版本动态更新。
4. 阶段性实践总结
（一）技术能力提升
输入输出处理：掌握多行文本输入时换行符的消除技巧，通过 Scanner 类的 nextLine () 与 trim () 组合使用实现格式净化
面向对象设计深化：
理解继承体系构建原则（如货物类型分层设计：普通货物→加急货物 / 危险货物）
熟练运用多态实现差异化逻辑（如通过接口 CalculatorRate 实现不同货物费率计算）
强化设计原则应用（单一职责原则指导类功能拆分，开闭原则支持业务扩展）
数据结构实践：通过 ArrayList 实现订单货物列表管理，掌握泛型集合的增删改查操作规范
（二）工程实践启示
调试策略优化：第二次作业中，因长时间调试未定位问题，通过阶段性休息后重新审视代码，快速发现逻辑漏洞，表明适度中断调试有助于提升问题定位效率
代码可维护性建设：
注释规范：需按功能模块添加说明，避免因注释缺失导致后期代码理解困难
单一职责：Main 类因语句过多导致复杂度超标，需通过方法拆分遵循单一职责原则
（三）方法论总结
通过两次迭代开发，形成以下实践范式：
需求分析→类图设计→核心逻辑伪代码→编码实现→测试验证的标准化流程
面向对象三大特性（封装、继承、多态）与七大原则的协同应用
格式错误优先排查（空白符、标点、文本匹配）→逻辑错误调试的问题定位顺序
未来需进一步强化 List 集合的高级操作（如排序、过滤），并通过设计模式学习提升代码架构的可扩展性。