第2次Blog作业

前言

题目集8相对于前面的题目集题目量较少，第1题点线面问题重构主要考察继承与多态，第2题雨刷程序功能扩展设计和第3题航空货运管理系统主要考察类的设计，而题目集9的大部分题目来源于题目集8的扩展，而全新的题目1魔方问题主要考察的也是类的设计，两次题目集除题目航空货运管理系统以外均给出类图参考，较简单，而题目航空货运管理系统无类图参考，需要自己独立思考，较难。

OPP8

设计与分析

类图设计与分析

题目集8的航空货运管理系统根据题目要求设计了Customer类，Goods类，Flight类，Order类，Main类。
Customer类用于表示客户信息，包含客户的编号、姓名、电话和地址等属性，提供了获取客户姓名和电话的方法，封装了客户相关数据，便于管理和使用客户信息 ；Goods类代表货物信息，有货物编号、名称、长宽高和实际重量等属性。实现了计算体积重量、实际重量、计费费率、运费等核心业务逻辑。Flight类描述航班信息，包括航班号、出发地、目的地、日期和最大载重等属性。提供了属性的读写方法。Order类用于管理订单信息，包含订单编号、日期、发件人和收件人信息、货物列表以及关联航班等，实现了计算订单总重量、总支付金额以及打印订单详情的功能。Main类是程序入口，负责从控制台读取用户输入信息，创建Customer、Goods、Flight和Order对象，并根据订单重量和航班载重判断是否能处理订单，最后打印订单信息，实现了基本的输入输出流程，能将各个类串联起来完成业务操作。

代码静态分析

代码共339行，没有注释，是因为在PTA中完成作业追求效率，并且题目较简单，不需要注释标明就可以理解代码作用。
代码中部分方法存在一定逻辑复杂度。Goods类的rate方法有多个if - else if条件判断，随着业务规则的变化，可能需要继续添加条件分支，会进一步增加复杂度。这在一定程度上拉高了整体代码的平均复杂度。

踩坑心得

1. 刚刚入手题目时一味的写，没有提前设计好类间关系。导致后续在类的职责出现混乱，进而必须重新设计，花费的时间还更多。
2. 题目附件的rate未加载出来，导致计算错误
3. 输出格式错误，用空格来输出导致结果错误。应该使用制表符。

改进建议

1.在编码前明确每个类的职责（如Goods类负责商品属性与计算逻辑，Order类负责订单管理，Main类负责输入输出），遵循单一职责原则，避免一个类承担过多功能（如将rate方法的业务逻辑拆分到独立的策略类中）。
2.Goods类的rate方法包含大量if-else if分支，扩展性差，可以使用switch等其他代码代替，减小复杂度。
3.输出表格尽量用指标符。

OPP9

设计与分析

类图设计与分析

在题目集8的基础上，将Good类，Customer类抽象化，新增个人和团队类，支付方式类。
在原系统基础上，将Customer类抽象，保留客户编号、姓名等通用属性与方法，新增Individual和Team子类。前者增加身份证号属性，后者添加营业执照号属性，二者重写方法区分客户类型，实现差异化管理。Goods类也进行抽象，包含货物基本属性与通用计算方法。派生出普通货物、易碎品、危险品等子类，针对不同货物类型设定差异化计费和运输逻辑。新增PaymentMethod类，涵盖多种支付方式枚举，具备支付处理功能并记录支付信息。在Order类中引入该类对象，完成订单支付闭环，提升客户支付体验与财务数据管理准确性。

代码静态分析

件有 342 行代码，含 163 条语句，分支语句占比 12.9% ，方法调用语句占 30% ，但注释行占比为 0%，不利于代码理解维护。代码含 9 个类和接口，平均每个类有 3.00 个方法，每个方法平均约 3.48 条语句 ，最复杂方法是 “ExpediteGoods.rate ()”，和题目集8的分析结果类似。

总结

题目集9的航空货运管理系统是题目集8的迭代，踩坑心得和改进建议和题目集8的一样，就不再列出了。题目集 8 与题目集 9 围绕航空货运管理系统的设计与扩展，系统考察了类的抽象、继承、多态等面向对象编程核心思想的应用，以及代码结构设计、业务逻辑实现和系统扩展性优化的能力。在题目集 8 中，通过设计Customer、Goods、Flight、Order、Main等具体类，初步实现了航空货运的基础业务流程，包括客户信息管理、货物计费、航班匹配及订单处理等功能。尽管代码结构较为清晰，但存在类职责划分不够细化（如Goods类承担过多业务逻辑）、方法复杂度较高（rate方法的多层条件判断）以及缺乏注释等问题，导致代码可维护性和扩展性受限。
题目集 9 在题目集 8 的基础上进行了系统性优化：通过抽象Customer和Goods类，引入Individual/Team子类和NormalGoods/FragileGoods/HazardousGoods子类，实现了客户类型和货物类型的差异化管理，符合 “开闭原则”；新增PaymentMethod类完善了订单支付闭环，提升了系统功能的完整性。此外，通过抽象类提取共性属性和方法，降低了类间耦合度，使系统结构更灵活。然而，代码仍存在注释缺失、部分方法复杂度较高（如ExpediteGoods.rate()）等问题，需进一步通过策略模式重构条件分支逻辑，并补充必要注释以增强可读性。

通过这两次题目集的实践，不仅巩固了面向对象编程的基础语法（如抽象类、接口、继承），更重要的是学会了如何运用设计原则和模式解决实际问题，提升代码的可维护性和扩展性。同时，意识到代码质量（注释、复杂度、格式）在工程化开发中的关键作用，以及前期设计和需求分析对系统架构的深远影响。