第二次大作业

0.前言
此次大作业较第一次大作业总共分为2次作业，较为简单，基本没算法，但代码量有所增加，第一次作业100分，第二次作业100分，完成情况较好，基本没失分的地方，但依旧有些方法使用不熟悉，印象不深刻，例如：工程模式，抽象等方法使用较少，还比较生疏需要加强练习。
1.第一次作业
（1）题目：
一、航空快递以速度快、安全性高成为急件或贵重物品的首选。空运以实际重量（GrossWeight）和体积重量（VolumeWeight）中的较高者作为计费重量。
计算公式：
体积重量（kg）= 货物体积（长×宽×高，单位：厘米）÷6000
示例：
若货物实际重量为80kg，体积为120cm×80cm×60cm，则：体积重量 =(120×80×60)÷6000=96kg计费重量取96kg（因96kg>80kg）。
二、基础运费计算
费率（Rate）：航空公司或货代根据航线、货物类型、市场行情等制定（如CNY 30/kg）。本次作业费率采用分段计算方式：

公式：基础运费 = 计费重量 × 费率
三、题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场所在城市，航班降落机场所在城市，航班日期，航班最大载重量）客户填写货运订单并进行支付，需要提供如下信息：
 客户信息（姓名，电话号码等）
 货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
 运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选航班号，订单日期）
 支付方式（支付宝支付、微信支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独计费。程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信息报表及货物明细报表。
四、题目要求
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开闭原则以及合成复用原则，除需要在PTA平台提交源码外，还需要在超星平台提交本次作业最终得分源码（首次提交最高分源码）的类图，评判标准为：
基础得分：PTA实际得分
设计因素：单一职责原则（40%）、里氏代换原则（20%）、开闭原则（20%）、合成复用原则（20%）
最终得分：基础得分扣减所有违背设计原则分值（违背所有四个原则的设计最终得分为0分）
（2）代码分析：

    类图：
    ![](https://img2024.cnblogs.com/blog/3634575/202505/3634575-20250522202455884-894036637.png)

    代码总行数：363行，代码行数较第一次大作业迭代前来讲有明显提升，表明代码量有所上升。

    语句：53行，代码较少，难度有所下降。

    分支语句百分比：3.8%，比例较低，表明分支逻辑不多，代码复杂性不大。

    方法调用语句：36个，这个值相对较低，说明代码代码调用不频繁，容易理解。

    代码注释百分比：0%，由于此次大作业较为简单，本人没有用到注释，使代码注释为0。

    类和接口：9个，分别使Main（主程序入口），Customer（客户类），OrderManage（订单管理类），Order（订单类），OrderItem（订单项类），Product（商品类），Payment（支付基类），WechatPay（微信支付子类），ALiPay（支付宝支付子类）。

    每个类的方法数：1个，数据较小，说明代码的复用性提高。

    每个方法中的代码行数：47行，代码行数较多，说明这段代码可能造成很多不必要写的内容，增加了代码的理解难度。

    最复杂的方法：没有较为复杂的方法。

    最大复杂度：0，因为没有复杂方法，代码简单，所以最大复杂度为0。

    最大代码深度：3，这是一个适中的值，表明代码中存在嵌套，且难度适宜，在理解上也不难，代码维护的难度也适中。

    平均代码深度：2.02，相对适中，表明代码中有一定程度的嵌套，整体上还可控。

    平均复杂度：0.0，没有复杂的类，最大复杂度也是0，因此平均复杂度为0.
（3）总体分析：
    一、代码结构分析​​

​​ 类与职责​​：
​​Main​​：程序入口，负责输入处理和结果输出。
​​ Customer​​：客户信息管理，关联订单管理（OrderManage）。
​​OrderManage​​：订单集合管理（未实现核心逻辑）。
​​Order​​：单个订单信息，计算总重量和金额。
​​OrderItem​​：订单项，关联商品（Product）。
​​Product​​：商品信息，计算运费规则（体积重量 vs 实际重量）。
​​Payment​​：支付基类（空实现）。
​​ WechatPay/ALiPay​​：支付子类（未实现具体逻辑）。
​​ 核心流程​​：输入客户、商品、航班信息 → 创建订单 → 验证重量 → 输出订单详情。
​​二、存在问题​​
​​未实现的核心功能​​：
OrderManage.addOrder()、Customer.pay() 等方法为空。
支付类（Payment 及其子类）未实现实际逻辑。
​​重复逻辑​​：Product.getPrice() 中重复的费率计算。
​​魔法数字​​：6000（体积系数）、35/30/25/15（费率）未提取常量。
​​ 未使用的字段​​：如 Customer 中的 address、Order 中的 time。
​​封装性不足​​：Product.rite 和 weight 字段直接暴露给外部类。
​​ 输入处理风险​​：输入顺序依赖性强，容易因输入错误导致崩溃。
三、改进建议
优化重复逻辑​​、增强健壮性​、定义支付接口​​、移除无用字段​​：删除 Customer.address 和未使用的变量、增强封装​​。
（4）总结：
通过实现核心逻辑、优化代码结构、增强输入校验和引入接口设计，改进后的代码将具有以下优势：
​​ 功能完整性​​：支付和订单管理功能可用。
​​ 可维护性​​：消除重复代码，常量命名清晰。
​​健壮性​​：输入错误不会导致程序崩溃。
​​扩展性​​：新增支付方式只需实现 IPayment 接口。
2.第二次作业分析
（1）题目：
一、计费重量的确定
空运以实际重量（GrossWeight）和体积重量（VolumeWeight）中的较高者作为计费重量。
计算公式：
体积重量（kg）= 货物体积（长×宽×高，单位：厘米）÷6000
示例：若货物实际重量为80kg，体积为120cm×80cm×60cm，则：体积重量 =(120×80×60)÷6000=96kg计费重量取96kg（因96kg>80kg）。
二、基础运费计算
费率（Rate）：航空公司或货代根据航线、货物类型、市场行情等制定（如CNY30/kg）。本次作业费率与货物类型有关，货物类型分为普通货物、危险货物和加急货物三种，其费率分别为：

三、题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场所在城市，航班降落机场所在城市，航班日期，航班最大载重量）客户填写货运订单并进行支付，需要提供如下信息：
 客户信息（姓名，电话号码等）
 货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
 运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选航班号，订单日期）
 支付方式（支付宝支付、微信支付、现金支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独计费。程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信息报表及货物明细报表。
四、题目要求
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开闭原则以及合成复用原则，除需要在PTA平台提交源码外，还需要在超星平台提交本次作业最终得分源码（首次提交最高分源码）的类图，评判标准为：
基础得分：PTA实际得分
设计因素：单一职责原则（40%）、里氏代换原则（20%）、开闭原则（20%）、合成复用原则（20%）
最终得分：基础得分扣减所有违背设计原则分值（违背所有四个原则的设计最终得分为0分）
（2）代码分析：

    类图：
    ![](https://img2024.cnblogs.com/blog/3634575/202505/3634575-20250522202614400-1459434444.png)
    ![](https://img2024.cnblogs.com/blog/3634575/202505/3634575-20250522202629545-512213141.png)

    代码总行数：566行，代码行数较第一次大作业来讲有明显提升，表明代码难度上升。

    语句：339行，代码上升，说明迭代后代码较为复杂。

    分支语句百分比：13.3%，比例较低，表明分支逻辑不多，代码复杂性不大。

    方法调用语句：53个，这个值相对较低，说明代码代码调用不频繁，容易理解。

    代码注释百分比：0%，由于此次大作业较为简单，注释为0。

    类和接口：18个，​​Customer​​：客户基类，管理客户基本信息及订单管理对象，Indivi​​：Customer 的子类，表示个人客户类型，​​Cor​​：Customer 的子类，表示企业客户类型，​​OrderManage​​：订单管理类，通过链表管理订单集合（功能未完全实现），​​Order​​：订单类，包含订单项列表，计算订单总重量和金额，​​OrderItem​​：订单项类，关联具体商品（Product），Product​​：商品抽象基类，定义计费规则（getPrice() 为抽象方法），Putong​​：Product 的子类，表示普通商品类型，​​Weixian​​：Product 的子类，表示危险品商品类型，Jiaji​​：Product 的子类，表示加急商品类型，​​Payment​​：支付方式基类，定义支付方法（空实现），WechatPay​​：Payment 的子类，微信支付实现（未实现具体逻辑），​​ALiPay​​：Payment 的子类，支付宝支付实现（未实现具体逻辑），Cash​​：Payment 的子类，现金支付实现（未实现具体逻辑），SimpleFactory1​​：商品工厂类，根据输入类型（如 "Normal"、"Dangerous"）创建不同商品对象，​​SimpleFactory2​​：客户工厂类，根据输入类型（如 "Individual"、"Corporate"）创建不同客户对象，​​SimpleFactory3​​：支付方式工厂类，根据输入类型（如 "Wechat"、"Cash"）创建不同支付方式对象。

    每个类的方法数：3.94个，这个数据较小，代码所调用的方法多，提高了代码的复用性。

    每个方法中的代码行数：3.15行，代码行数较少，说明这道题目并不是很难，较为简单。

    最复杂的方法：Jiaji.getPrice(),在388行，计算这个方法较为复杂，用了多个if，else使代码难度上升，复用性下降。

    最大复杂度：15，这是一个比较危险的值，一般公司的复杂度不会超过10，而15这个值比较危险，这意味着，该方法可能逻辑比较复杂，有必要进行重构降低复杂度。

    最大代码深度：5，这是一个较高的值，表明代码中存在较深的嵌套，可能造成代码难以理解，增加代码维护的难度。

    平均代码深度：2.87，相对较高，表明代码中有一定程度的嵌套，整体上还可控。

    平均复杂度：1.8，这个值相对适中，说明代码可读性较高，容易理解。
（3）总体分析：
    一、代码分析：

​​ 功能概况​​：
实现物流订单管理系统，支持客户、商品、订单管理及支付。
使用简单工厂模式创建对象，通过策略区分普通商品/危险品/加急商品的运费计算。
根据客户类型（个人/企业）计算折扣。
二、​​主要问题​​：
​​ 重复代码​​：商品价格计算逻辑在多个子类中重复。
​​ 输入风险​​：缺乏输入校验和异常处理。
​​ 支付空实现​​：支付模块未实现具体逻辑。
​​ 封装不足​​：类字段直接暴露（如 Product.rite）。
​​魔法数字​​：计费规则中的固定数值未提取为常量。
​​ 未使用代码​​：如 Customer.address、Order.time。
​​ 工厂类冗余​​：工厂类设计可以进一步优化。
三、具体改进建议​：
输入验证与异常处理​、优化工厂类​、 消除重复的计费逻辑​、封装类字段​、清理未使用字段​。
（4）总结：
​​增强健壮性​​：输入错误友好提示，避免程序崩溃。
​​ 提高可维护性​​：消除重复代码。业务常量集中管理，修改费率调整一下，使它更加完善。
​​ 提升扩展性​​：新增支付方式只需实现接口。
3.总体总结
本次大作业代码较为简单，相比第一次难度有所下降，但还应该改进代码，使代码难度下降，复用性提高，增强扩展性，并且在工厂模式的应用方面不足，对工厂模式的认识较浅，还应该提高继承，抽象方法的使用，在这方面再进一步，尽量优化代码，使代码变得通俗易懂。