Blog2-航空货运管理系统
面向对象程序设计题目集8~9总结
- 前言（总结两次题目集的知识点、题量、难度等情况）
题目集8
一共有三道题。这次前两道题都是之前题目集出现过的题目，只是加入了不同的设计要求进行拓展，比如点线面问题要求使用继承与多态。但是总体难度适中，能够有效帮助我们认识、学会使用继承与多态这些知识点。
题目集9
一共有三道题。前两题同样是较为基础的题目，第一道题是新出现的魔方问题，第二题依旧是之前出现过的点线面问题重构，这次的要求是使用容器类，难度上感觉会比题目集8稍微高一点，但是努努力还是可以解决的。同样通过这几道题目可以更好帮助我们上手新的知识点。
【航空货运管理系统迭代设计】
这两次的迭代题目有一定的难度，需要考虑的方面较多。第一次的题目主要考察的是类设计，以及一些面向对象的设计原则，比如单一职责原则、里氏代换原则、开闭原则、合成复用原则等等，然后就是注意一些题目的设计细节，比如费率分段计算、输出格式等。第二次的题目要求加入继承与多态，新增了依赖倒转原则，实际上还使用了接口。难度较上一次有一点提升。
- 设计与分析
由于前几道题目难度正常，只需要正常完成题目要求就好，所以这里重点分析两次航空货运管理系统程序。
- 题目集8
题目描述
航空快递以速度快、安全性高成为急件或贵重物品的首选。本题目要求对航空货运管理系统进行类设计，具体说明参看说明文件。
这是第一次代码的类图：
SourceMontor分析：
- 分支语句占总语句数的百分比为 6.3% 。该比例相对较低，表明代码中条件判断逻辑不算复杂，代码执行路径较为清晰，整体逻辑相对简洁，在理解和维护上相对容易，降低了因过多分支导致逻辑混乱的风险。
- 注释行占比为 0.0% ，这是非常糟糕的状况。代码缺少注释会极大地影响可读性，无论是自己日后回顾代码，还是其他人接手维护，都难以快速理解代码的功能和意图，可能会耗费大量时间去梳理代码逻辑，增加了维护成本和出错几率，需补充注释。
- 有 9 个类和接口 ，说明代码有一定的模块化程度，对功能进行了一定程度的拆分。平均每个类有 2.33 个方法 ，表明类的功能分散度尚可，没有过度集中在少数类中，但也可能存在类的职责划分不够清晰的情况，需要进一步审视。每个方法平均有 4.90 条语句 ，说明方法规模较小，功能相对简单，符合良好的代码设计原则，更易于理解、测试和维护。
- 最复杂方法位于第 75 行 。这提示我们此处代码逻辑可能相对复杂，或许存在较多的嵌套、条件判断或计算逻辑等。需要对该方法进行重点审查，考虑是否能通过代码重构，如提取子方法、优化算法等方式，来降低其复杂度，提升代码质量。
从实际代码来看，还是实现了基本的航空货物订单系统功能，采用了面向对象的设计原则，合理运用了抽象与继承，具有可维护性和可扩展性基础。但在输入验证、异常处理、代码复用和业务逻辑灵活性方面还有改进空间，同时还需要添加代码注释。
- 题目集9
题目有所变化，增加了要求。航空快递以速度快、安全性高成为急件或贵重物品的首选。本题目要求对航空货运管理系统进行类设计，具体说明参看说明文件。
这是第二次代码的类图：
SourceMontor分析：
- 分支语句占总语句数的百分比为 15.0% 。该比例处于中等水平，表明代码中存在一定数量的条件判断逻辑，但尚未达到过度复杂的程度。相较于上一版（6.3%），分支逻辑有所增加，可能意味着业务需求的复杂度提升，或者存在部分逻辑可以进一步优化以减少条件判断。整体而言，代码执行路径仍较为清晰，但需关注分支嵌套层级是否过深，避免影响代码的可读性和可维护性。
- 注释行占比为 1.0% ，虽然相较于上一版的 0.0% 有所改善，但是仍然严重不足。代码注释的极度匮乏极大地影响了可读性，如果自身回顾代码，需要花费大量时间理解代码逻辑和意图。这种情况增加了维护成本和出错风险，急需在关键业务逻辑、复杂算法、类与方法功能说明等位置补充详细注释，以提升代码的可维护性。
- 有 8 个类和接口 ，说明代码进行了一定程度的模块化设计；平均每个类有 7.00 个方法 ，表明类的功能较为丰富，但也可能存在类的职责不够单一的情况。过多的方法可能导致类的复杂度升高，违背单一职责原则，需要审视是否可以进一步拆分功能，提高代码的内聚性和可维护性。
- 最复杂方法未定义行号 ，可能由于工具统计问题或代码中方法复杂度相对均匀。但结合类和方法指标分析，若存在单个类中方法数量较多且平均语句数较高的情况，可能存在潜在的复杂方法。
从实际代码来看，还是实现了一个功能完整的航空货物订单系统功能，采用了面向对象的设计原则，具有可维护性和可扩展性基础。通过接口和抽象类的运用，实现了多态性和代码复用，符合开闭原则。但在输入验证、异常处理、业务逻辑灵活性方面还有一定的改进空间。
- 踩坑心得
虽然这两次迭代题目我都做出来了，但是仍然有踩坑的地方。第一次的题目，对于继承关系中父类子类的写法还不是太熟悉，导致缺了部分代码编译错误了，然后就是开始没有考虑到遇到异常情况应该怎么办（指输出）；对于正常的输出格式起初也有点小问题。
第二次题目要求使用继承与多态，大体思路与之前相同。但是最初我在计算费率时忘记了题目是要求根据货物重量来决定费率，导致最终结果一直有错。再就是对于异常情况时的输出格式我又看错了，这很不应该。
- 改进建议
- 可以在编码前构建清晰的类结构和业务逻辑模型。在航空货运订单这个系统中，涉及客户、货物、航班、订单等对象。我们可以先绘制类图来明确各对象属性和方法，以及它们之间的关联关系，比如客户与订单是关联关系，货物与订单是聚合关系等。这能提前梳理清楚逻辑，避免编码时逻辑混乱，降低后期的修改成本。
- 要严格遵守单一职责原则。比如像货物相关类，应该专注于货物自身属性（如尺寸、重量）以及计费逻辑处理，而不应该掺杂订单管理或者航班适配等其他职责；订单类则聚焦订单信息整合、总费用和总重量计算以及报表生成等。每个类只负责单一明确的功能，这样代码的可读性、可维护性更高，测试也更便捷，出现问题时能快速定位责任类。
- 不能混淆输入处理与业务逻辑执行。而是应该先规范处理用户输入，验证其合法性（比如货物尺寸、重量是否为正数，航班载重是否合理等），将合法输入转化为系统内部可处理的对象和数据结构，如构建货物对象、航班对象等。在业务逻辑执行阶段，依这些规范数据进行操作，如订单计算运费、判断航班是否可承载货物等。不应该在执行核心业务逻辑时随意插入输入校验或调整输入相关逻辑。调试时，要从整体出发，思考数据从输入到输出经过的各个环节，通过各种方式，定位不符合预期的地方，而不是只靠零散的条件判断来修补逻辑漏洞。
- 总结
通过这两次关于航空货运管理系统的题目练习，我对面向对象程序设计的学习有了更深入的体会。
- 通过对航空货运这一现实业务场景进行分析，我逐渐学会了从中提取关键对象，像客户、各类货物、航班以及订单等，并运用 Java 中的类与方法为它们合理分配职责，构建起相对清晰的数据模型和业务流程调度结构。
- 在不断完善代码的过程中，我的单一职责原则和模块化思维得到了很好的锻炼。我领悟到 “一个类只负责一件事” 这一原则的重要性。例如，将货物的属性管理、费率计算等功能单独放到对应的货物类中，把客户信息维护、折扣率获取放在客户类里，再让订单类专门整合各方信息、计算总费用和生成报表等操作。通过这样划分功能，将原本复杂的业务逻辑拆解成一个个独立的模块，程序的结构变得清晰明了。当需要排查问题或者进行功能拓展时，能迅速定位到相应模块，降低了调试和拓展的难度，也让代码整体的可维护性有了显著的提升。
- 当然，我也明白自己在很多方面还存在欠缺。比如在类与类之间的设计上，有时不能很合理地构建它们之间的交互关系，导致代码在整体的流畅性和逻辑性上有所不足。尤其是在算法的运用方面，能力还比较薄弱，代码的运行效率不是很高。此外，代码的可读性方面也还有很大的改进空间，虽然功能可以实现，但缺乏注释，使得在阅读代码时需要花费较多精力去理解其意图。这些不足都提醒着我，在后续的学习中需要有针对性地加强训练，提升自己在这些方面的能力。
- Java课程方面，老师讲解没什么问题，配合线上作业加以练习可以达到学习效果。
浙公网安备 33010602011771号