面向对象程序设计（Java）题目集8~9中航空货运管理设计总结BLOG
一.前言
在最新两次的PTA编程作业中，发布了题目集8~9中有关航空运输订单的题目，以抽象类的使用和类的多态继承为核心载体，通过两次迭代作业分步推进完成，逐步引导我们从单一类的货物，支付方式，用户的基础单个类过度到应对更复杂场景的类的继承，实现多种类的多态继承使用，以及深化了我在编程过程中对代码封装，复用性，单一职责原则等意识原则的更深理解，对多态的使用时机，如何使用和作用的理解也得到了加深。这两次题目集不仅是对编码能力的训练，对方法继承思维和类类型分类的考验的要求重点有所加深，对方法的重写，以及父类子类的使用相对之前进行过的代码设计都有了重点加高的要求，也是这两次题目集的重点所在。题目对算法的要求降低，对设计原则和类的使用要求有所提高。
题目集所涉及知识点：
这两次题目集着重考察了Java面向对象程序设计中继承与多态的核心概念及其工程化应用。通过航空货运管理系统的迭代设计，检验了在类层次结构构建、行为抽象化以及动态绑定机制等方面的知识点。题目要求通过继承机制建立类间关系，并利用多态特性实现行为的差异化表达（如不同货物类型的计费规则、多种支付方式的处理逻辑）。需合理运用抽象类与接口定义契约，通过方法重写（Override）实现动态绑定，并借助向上转型机制简化集合操作。深化了"一个接口，多种实现" 设计理念的理解，更要求其在复杂场景中灵活应用继承与多态的协同模式，以达成系统的可扩展性与可维护性目标。题目中涉及的动态类型识别、抽象设计以及开闭原则的贯彻，全面考察了运用面向对象范式构建继承多态程序架构的能力，充分体现了继承与多态作为面向对象编程核心的作用和便利。
题目集题量感受：
题目集的题目数量总体上较少，但具体内容并没有因为题量较少而导致考察的内容不足，很好地通过少量而精的题目对学生的知识点以及方法对象的设计进行了多方面的检测。完成繁琐度不会太多，也不会过于轻松。能够让我较好地完成我对于面向对象设计知识的练习。也能较好地训练我的基础编程能力和习惯，处于一个比较合适的范围。
题目集难度感受与建议：
相对于前几次的题目集，8~9两次题目集的难度明显有所下降，虽然迭代作业中程序的相对难度有所上升，复杂度也不低，但着重考察的内容由算法转向面向对象程序设计的思想的原则以及方法，对困难的算法所涉及的知识点内容减少，算法的难度明显下降，而对面向对象程序设计思想所考察的部分则越发深入，通过部分降低难度的题目提高了学生的做题积极性，对能力的检测保证了一定的门槛的同时也确保了程序设计思想的考察，考验了更严格正确和类构造以及对多种类型对象设计多态类和类方法继承的处理能力。
二.设计与分析
在本两次题目集8~9中，有关航空货运管理的两道迭代题目为主要核心以及关键考察内容，考察了题目集所涉及的最主要的知识点和思想，在此对其专门分别进行分析
第一次航空货运管理题目设计与分析（题目集8）
题目要求
航空快递以速度快、安全性高成为急件或贵重物品的首选。本题目要求对航空货运管理系统进行类设计，按顺序分别输入客户信息、货物信息、航班信息以及订单信息，并根据输入的信息设计对应的类，如果航班载重量可以承接该订单，处理并输出订单的信息。
SourceMontor报表
SourceMontor复杂度表
程序类图
程序设计分析
MAIN类：作为代码的主要框架，通过输入完成外部数据信息的接收，并根据接受的信息处理，依次获取用户编号、姓名、电话、地址等用户信息，以及货物数量、每件货物的编号、名称、长宽高和重量等货物信息，还有航班号、出发地、目的地、日期、最大载重等航班信息，以及订单号、订单日期、发件人和收件人的地址、姓名、电话等订单信息。然后根据这些输入信息分别创建Users、Item、Plane、Senders、Getters实例，并进一步创建Order实例，将货物添加到订单中。检查订单总重量是否超过航班最大载重，若超过则提示航班超载无法承载订单，未超过则显示订单所有信息，包括客户、航班、订单号、日期、发件人、收件人、订单总重量、总费用以及货物明细等内容。
People类(抽象类): 作为所有人员类的基类，定义了人员的基本属性（姓名、电话、邮箱 / 地址）和抽象方法show()。通过抽象方法强制子类实现信息展示逻辑，实现了代码复用和多态性。
Users类(客户类)：继承自People，增加了用户编号属性。用于表示系统中的客户，show()方法打印客户基本信息及订单提示，连接了客户与订单系统。
Senders(发件人类)：继承自People，专用于存储发件人信息。show()方法格式化输出发件人的姓名、电话和地址，为订单提供发货方信息。
Getters（收件人类）：继承自People，专用于存储收件人信息。show()方法格式化输出收件人的姓名、电话和地址，为订单提供收货方信息。
Item（货物类）：包含货物的核心属性（编号、名称、尺寸、重量），并实现了运费计算逻辑：
根据体积和毛重计算计费重量，基于重量区间动态计算费率，自动计算每件货物的运费。
Plane（航班类）：存储航班的基本信息（航班号、起止地、日期、最大载重）。主要用于订单与运输工具的关联，并提供载重检查功能，确保订单不超过航班承载能力。
Order（订单类）：整合了所有核心业务逻辑，关联用户、发件人、收件人、航班和货物列表，计算订单总重量和总费用，提供完整的订单信息展示功能，是系统的核心调度类，通过组合其他类实现完整的订单管理流程。
问题分析：
从SourceMontor报表，SourceMontor复杂度表，PowerDesigner类图来分析，我们能够清晰地发现代码存在以下的问题
各个类的方法复杂度较低，嵌套层次较低： 本次程序设计以面向对象思想为核心，注重类的封装、继承与多态的运用，因此在方法复杂度与嵌套层次的控制上表现出明显倾向。从代码结构看，各个类的方法复杂度普遍较低，嵌套层次多维持在 2-3 层以内，这使得代码逻辑清晰易读，符合面向对象设计中 “单一职责” 和 “低复杂度” 原则，便于开发者理解类的功能边界与业务流程。然而，受限于对面向对象设计原则的侧重，部分代码在细节实现上存在优化空间，存在重复代码片段，显得冗杂沉余。
注释率较低： 从图表所示，代码整体存在的注释仅限于一些程序的核心运行部分，代码注释较为合理，但是仍然存在一定的缺失，影响了代码的可读性，以及进行代码优化时的困难程度，但相对之前有所进步。
心得
在初次接触类似本题这样类构造数量较多，对类的多态继承等使用更加着重而非重点考验算法的题目之后，我非常清楚地感受到了在遵守几大设计原则的情况下，java面向对象程序设计的高度条理性，在不断通过对类的设计的过程中，我对抽象类，容器类等各种不同类的使用更加习惯，对父类子类的作用和原理也有了更加清晰的认知，不再不适应，能够熟练地根据程序的需要来设计类和属性。通过对多态继承和几大设计原则（如单一职责、开闭原则、里氏替换原则等）的使用，我的代码的可读性，复用性，扩展性都得到了巨大的提升，对于复杂的大量数据也能够有条理地对输入进行正确的处理，大大提高了我在设计程序时的正确性和便利性，在往后的程序设计中，我也会继续坚持遵守这些原则，并将多态和继承等概念更好地融入程序设计之中。
第二次航空货运管理题目设计与分析（题目集9）
题目要求
该题目在第一次航空货运管理设计题目的基础上，额外强调了对于继承多态的作用，主要表现在对于新扩展的三种货物类型和两种用户类型，以及三种不同的支付方式类型上，并为之设置了新的额外计算规则，需要围绕不同的情况来设计符合要求的多种子类，满足不同对象所需要的不同的计算规则和功能，满足多态和继承的要求。
程序设计
SourceMontor报表
SourceMontor复杂度表
程序类图
程序设计分析
在设计该迭代题目时，因为输入信息的修改和对于用户，货物，支付方式的种类产生了分类，需要额外设计对应的子类并设计对应子类的代码，同时因为题目对类的继承多态有了更严格的要求，通过抽象类结合继承的方法来实现对于普通货物，加急货物，危险货物以及团体用户和单体用户的子类需求，让子类继承父类的方法和属性，满足题目和程序输入需求。
Users1类： 继承 User，代表个人客户，show() 方法输出客户基本信息及订单提示，折扣率 li 固定为 0.9。
Users2类： 继承 User，代表团体客户，show() 方法与 Users1 相同，折扣率 li 固定为 0.8。
抽象类Item： 定义货物的基础属性（编号、名称、尺寸、重量等）和抽象方法 Costly()，计算运费费率。构造方法计算体积重量、计费重量和基础运费，子类实现具体费率规则。
NormalItem类： 继承 Item，代表普通货物，实现普通货物的运费费率计算规则（低重量段费率较高，随重量增加递减）。
DangerousItem类： 继承 Item，代表危险品，费率高于普通货物，实现危险品专属费率规则（各重量段费率均较高）。
ExpediteItem类： 继承 Item，代表加急货物，费率介于普通与危险品之间，实现加急件专属费率规则。
抽象类 pay： 定义支付方式的抽象类，包含支付金额属性 cost 和抽象方法 show()，子类实现具体支付方式的输出逻辑。
Wechat/ALiPay/Cash类： 均继承 pay，分别实现微信、支付宝、现金支付的 show() 方法，格式化输出对应支付方式的金额。
问题分析：
在进行第二次迭代题目时，总体上因为代码处理逻辑并没有与第一次迭代题目存在太多的差异，而是注重于对类的继承多态的使用而不是着重于高难度和复杂的算法，所以Source Monitor工具给出的分析结果中，第二次分析的复杂度与数据与第一次并不存在太多差别，我出现的问题也主要集中在对于类的继承的实现上，比如通过设计NormalItem类，DangerousItem类，ExpediteItem类继承抽象类的方法，并实现不同的计费费率计算，以实现多态，但在进行对父类方法的继承时，我因为没有在子类中对父类中抽象化的方法均进行实现，导致了编译错误，让我意识到了对于抽象方法实现的必要性和不可忽视性。
心得
在完成第二次迭代作业的过程中，因为其与第一次迭代作业的差异较小，以及和第一次迭代作业相同的对算法的较低要求和对于类的继承多态的使用的严格要求，导致了我在完成作业时出现的一系列问题和对题目要求的没有完美实现，在类的方法中代码的具体实现也存在有部分冗余使用，对于题目的迭代代码也仍然存在很多可以优化的问题，而Source Monitor工具所展示的分析结果也说明了代码仍然存在很多可以改进的地方，在往后的作业中，我要以更严格的态度来面对需求。同时吸取本次作业中有关类的继承与多态的使用的经验，在往后对类进行多态设计时能够遵循规则和正确的经验。
三.踩坑心得
出现的问题
- 1、对于题目计算逻辑错误认识导致的错误： 在第一次迭代设计程序代码时，我一开始对题目里实际重量和体积重量的选取规则产生了偏差，误以为只需按实际重量处理即可，完全没意识到在航空订单场景中，体积重量对计费规则和超载判定有着关键影响。这种误解让我在编写计费重量的处理逻辑时出现了方向性错误，没有考虑到两者之间的比较和取舍，导致后续代码在处理不同类型货物时无法正确反映真实业务需求。在做题过程中，程序运行结果始终与预期不符，我陷入了卡壳状态 —— 当输入体积较大但实际重量较轻的货物信息时，计算出的运费和超载判断结果明显不合理，却难以快速定位问题根源。为了找出错误，我反复使用不同的输入内容进行实例测试，尝试了多种可能的场景组合，在一次又一次的调试和观察中，终于发现了问题的核心：航空订单的超载判定和计费逻辑需要综合考虑实际重量与体积重量，取较大值作为计费重量，而我之前的代码忽略了体积重量的计算和比较。意识到这一点后，我重新梳理了逻辑，调整了代码中计费重量的处理方式，确保其符合题目要求，最终让程序正确运行，成功解决了困扰已久的问题。这次经历让我深刻体会到，对题目需求的准确理解是编写正确代码的基础，而反复测试和调试则是发现和修正逻辑漏洞的关键手段。
- 2、没有给代码添加详细的注释导致的代码可读性较低，只在部分重要代码处使用了注释，修改查找代码时难以找到具体位置： 我最初仅在部分自认为关键的代码位置简单标注了注释，这导致代码的可读性虽然有了一定的保证，但到代码细节上明显偏低。由于缺乏系统的注释说明，各个类内部代码的职责实现、方法的具体功能以及关键逻辑的设计意图都未能清晰体现，使得后续修改和查找代码时困难重重。例如，当需要调整某个业务规则（如运费计算逻辑）时，由于没有注释指引，只能逐行阅读代码来定位相关部分，不仅耗费大量时间，还容易因对代码逻辑的理解偏差引发新的问题。尤其是在处理多层级类调用或复杂业务流程时，难以快速理清各模块之间的依赖关系，极大降低了开发效率。这次经历让我深刻认识到，注释是代码不可或缺的组成部分，它不仅是对代码的 “翻译”，更是帮助开发者理解和维护程序的重要工具，只有养成全面注释的习惯，才能确保代码在后续迭代中保持良好的可维护性和拓展性。
- 3、对继承和抽象化的机制和设计不够了解，没有对抽象化的父类中的方法及时进行实现： 在设计程序时，由于对继承和抽象化机制的理解不够深入，我未能充分掌握父类与子类之间的职责划分。在定义抽象父类（如People）时，虽然声明了抽象方法，但在创建子类时，未能及时实现这些抽象方法，导致程序编译报错。这一问题暴露出我对抽象类的核心作用认知不足，抽象类通过定义未实现的方法强制子类遵循统一接口，而子类必须完整实现这些方法才能保证多态性的正确运行。由于缺乏对这一机制的清晰认识，我在编写子类代码时往往先关注属性的继承，忽略方法实现的完整性，直到程序运行出错才意识到问题所在。通过这次教训，我深刻体会到继承不仅是属性的复用，更重要的是对抽象方法的上下级式实现，只有严格遵循抽象类的设计规范，才能确保类体系的完整性和可扩展性，避免因机制理解偏差导致的结构性错误。
四.改进建议
在经过航空货运管理程序设计作业中暴露的共性问题后，我对题目有了更多不同的感受，因此我提出了以下系统性改进方向：
方法设计优化，提高模块化程度 在计算方法的设计上，避免将多种计算规则混杂在同一模块中。例如，将货物运费计算、重量校验、折扣应用等逻辑按功能划分为独立的计算模块，确保每个模块仅负责单一类型的计算任务。通过这种方式，既能清晰界定不同计算规则的边界，也便于后续对特定计算逻辑（如费率调整、折扣策略变更）进行独立修改或扩展，同时提升代码的可读性与可维护性，使整个计算流程更符合高内聚、低耦合的设计原则。比如将对于计费重量的计算选择从构造方法中剥离出来。
将注释落实补全到绝大多数代码中，保证代码能够根据注释进行高效的检查 在代码中系统性补全注释，覆盖类、属性、方法三级，说明设计意图与职责边界，注释详述功能逻辑与输入输出约束，确保维护时可以通过注释即可理解代码架构，快速定位问题与修改点。也提高在往后的迭代作业中代码的可读性。
五.总结
通过完成题目集 8~9 中航空运输订单相关的两次迭代编程作业，我在 Java 面向对象程序设计的继承与多态应用方面有了显著提升。第一次作业围绕航空货运管理系统的基础类设计，通过定义 People 抽象类及其子类 Users、Senders、Getters，以及 Item、Plane、Order 等类，实现了客户、货物、航班及订单信息的处理，深刻体会到抽象类对代码复用和多态性的支撑作用，也认识到合理封装类属性与方法的重要性。第二次作业在第一次基础上扩展了三种货物类型、两种用户类型和三种支付方式，通过继承抽象类并实现不同计费规则、折扣策略及支付逻辑，进一步掌握了多态在复杂业务场景中的灵活运用，理解了 “一个接口，多种实现” 的设计理念如何通过方法重写和动态绑定实现系统的可扩展性。
在设计与实现过程中，我遇到了计算逻辑理解偏差、注释不足、抽象方法实现不完整等问题，通过反复调试、补全注释和深入理解继承机制逐步解决，认识到准确把握题目需求、遵循设计原则（如单一职责、开闭原则）及规范编码习惯的重要性。两次作业虽难度较之前有所下降，但对面向对象设计思想的考察更加深入，不仅训练了类层次结构构建和多态编程能力，也强化了代码的可维护性和复用性意识。未来，我将继续优化方法设计的模块化程度，加强注释的完整性，更熟练地运用继承与多态构建灵活、健壮的程序架构，提升解决复杂问题的能力。
对于多态和继承的运用，我也进一步明白了其应用场景和作用，通过继承能让我在设计类时复用父类的属性与方法，构建层次结构并规范子类行为，而多态则基于继承，使不同子类对象通过统一接口实现差异化功能，提升系统的扩展性与灵活性。二者协同工作，帮我优化代码结构，增强应对需求变化的能力。让我的编程过程更加条理化，极大地降低了我在面对较多内容的编程任务时的混乱不知所措的情况，让我受益匪浅，清楚的感受到了多态思想和设计原则对于编程的帮助。
建议与意见
这次的两次迭代作业相比之前明显降低了算法上的要求，难度上降到了一个适当合适的程度，既能考验学生面向对象设计的编程能力，也不会因为题目过于困难而打消学生进一步钻研代码的毅力，在测试点的分数分配上也较为均匀，很好的提高了学生编写程序时的积极性。也能够十分清楚地让做题的学生感受到类的方法继承和多态在实际项目应用中的表现和作用，让学生熟悉设计原则和继承多态在实例中的使用和运用以及相关的设计思想。
浙公网安备 33010602011771号