题目集8~9第二次Blog作业

前言：本次航空货运管理系统作业，第一次主要考察类设计：Customer（客户信息）、Goods（货物信息，包含计费逻辑）、Flight（航班载重管理）、Order（订单信息汇总与输出），同时考核单一职责原则，里氏代换原则，开闭原则，合成复用原则。第二次则着重考察继承与多态的使用：引入抽象类Cargo封装通用货物属性，具体货物类继承并实现getRate()方法。Customer类新增customerType（个人/集团）getDiscountRate()方法。Order类通过List管理多货物，计算总费时需遍历货物并应用折扣，同时扩展面向对象设计原则新增依赖倒转原则。本次作业相较于电梯题目集题量，难度都有所下降，但本次作业因为没有类图，需要自己设计，对我来说有点困难。
第一次航运程序：
作业要求：本次题目模拟某客户到该航空公司办理一次货运业务的过程，航司提供航班信息，客户填写货运订单并进行支付。
设计与分析：
类图：

Customer类
属性：customerId（客户编号，int）、customerName（客户姓名，String）、customerPhone（客户电话，String）、customerAddress（客户地址，String） 。
Goods类
属性：goodsId（货物编号，int） 、goodsName（货物名称，String）、width（宽度，double）、length（长度，double）、height（高度，double）、weight（重量，double） 。
Order类
属性：orderId（订单编号，int）、orderDate（订单日期，String），关联Customer类对象（customer ）、Flight类对象（flight ）、Goods类对象数组（goodsList ），以及记录总重量（totalWeight ）和总运费（totalShippingFee ）。
Flight类
属性：flightNumber（航班号，String）、departureAirport（出发机场，String）、arrivalAirport（到达机场，String）、flightDate（航班日期，String）、maxLoadCapacity（最大载重，double）、currentLoad（当前载重，double） 。
Main类
作为程序入口，用于启动整个系统，执行主要业务逻辑流程。
源码分析：

解释：
1、代码最大复杂度为5，整体复杂度尚可，较上次电梯程序有较大减少。
2、类和接口数量为4个体现了一定的面向对象设计，将功能进行了初步分类。
3、平均每个类的方法数为5.25，说明类的功能较为丰富，单一职责原则实现的不是很好。
改进建议：
1、在写代码时养成写一点注释的习惯，方便后续阅读，修改，扩展。
2、在类设计时检查类职责，审视类中方法，确保每个类职责单一，避免功能过度集中。
踩坑心得：

在此次输出中订单总重量为118.5，微信支付金额应为2937.5，在PTA的样例中体积重量时小于实际重量的所以计算出来的结果没有问题（此时的订单重量为实际重量相加，不牵扯体积重量），但如果体积重量大于实际重量的话就会导致出错。笔者因为通过了样例就没有考虑的这一情况，解决方案为：在Goods类中添加体积重量计算逻辑，并在计费时取两者较大值。（添加：calculateVolumeWeight()、calculateChargeableWeight()）。
第二次航运程序
作业要求：本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开闭原则以及合成复用原则、依赖倒转原则。
设计与分析：
类图：

Customer类
属性：包括customerType（客户类型） 、customerId（客户编号）、name（客户姓名）、phone（电话）等。
Order类
属性：涵盖orderId（订单编号）、orderDate（订单日期）、senderName（寄件人姓名）、receiverName（收件人姓名）等众多与订单相关信息。
Flight类
属性：包含flightNumber（航班号）、departure（出发地）、arrival（目的地）、maxWeight（最大载重）等。
Cargo类（抽象类）
属性：有cargoType（货物类型）、cargoId（货物编号）、width（宽度）、height（高度）等描述货物特征的属性。
NormalCargo类
继承自Cargo类。
DangerousCargo类
继承自Cargo类。
ExpensiveCargo类
继承自Cargo类。
Main类
程序的入口点，程序执行从这里开始。
源码分析：

解释：
1、代码最大复杂度为9，处于较低水平，代码结构较为清晰
2、代码注释占比为0%，需要着重关注。
3、继承关系清晰，符合开闭原则。
改进建议：
1、Main.main()复杂度较高，可能违反单一职责原则，需要注意。
2、抽象类与接口使用不足，cargo作为抽象类仅提供了属性和方法，为强制子类实现必要的行为。
踩坑心得：
正确结果

错误结果
从图中可看出在应交运费上出现了错误。

程序	货物明细中的 “应交运费” 计算方式	总费用计算方式
正确的	基础费用（计费重量 × 费率）	总基础费用 × 折扣率
错误的	基础费用 × 折扣率	每个货物单独折扣后累加

修改计算方式后，实现了程序全部功能。
总结：
两次航空货运管理系统作业围绕面向对象设计展开，第一次通过类设计实践单一职责等原则；第二次运用继承与多态，引入抽象类和子类实现计费逻辑差异化，同时深化开闭、依赖倒转等原则。作业中解决了体积重量计算、费用折扣等问题。第一次根据需求自行设计较复杂的类，刚开始无法确定有哪些类，这些类对应什么功能，很难实现单一职责原则，通过学习与询问基本解决了问题。在第一次作业中Order 类承担了订单信息管理、运费计算、载重更新等多项职责，导致类复杂度较高，通过第二次作业优化，将计费逻辑转移至 Cargo 抽象类及其子类（如 NormalCargo、DangerousCargo），Flight 类专注于载重管理，Order 类仅负责订单信息汇总，显著提升了类的职责清晰度。第一次作业后的第二次作业在面向对象设计原则上不仅新增了依赖倒转原则，同时对里氏代换，合成复用，单一职责原则的要求更加高。通过这两次作业只能说简单了解了面向对象设计原则及其应用，未来还需进一步的学习，并能较为熟练地运用。第二次作业中的继承与多态，引入了抽象类Cargo作为所有货物类型的基类，定义了货物的通用属性和行为，Order类使用List存储不同类型的货物，通过多态调用子类方法。初步了解到了，无继承：每个货物类需单独定义长宽高、重量等属性和计费逻辑，代码冗余严重，而有继承：基类封装共性，子类只需关注差异化实现（如费率、体积重量计算公式）。通过多态，系统可在运行时根据实际对象类型调用相应方法，无需编译时确定。目前笔者只了解到了这些皮毛，对继承与多态的学习也任重而道远。