第二次博客作业，有关航空货运管理系统的程序代码分析

一，前言

本次题目集8到9，对航空货运管理系统进行了迭代分析。本次的大作业我成功通过了所有的测试点，相较于上一次的电梯程序代码，我这次变得更加熟练了一些，也使我从紧绷焦虑的心情中得到了缓解。这次的迭代作业，我从中学到了许多知识，例如抽象类，接口的使用，还有代码程序的开闭原则，代码程序的继承和多态。本次题目集的难度我认为不算大，如果按照正确地思路写下去是能写出来的。合理的去运用，使用这些方法，遵守这些原则，我们的代码将会变得十分“美观”，具有良好的可读性，也具有优秀的可扩展性，时效性。总之，java这门语言讲究的就是一种面向对象的一种解决问题的方法，需要用合理分派任务，所有的代码齐心协力地去完成任务。下面我对我的程序代码进行分析。

二，代码的设计与分析

1，第一次航空货运管理系统程序

航空快递以速度快、安全性高成为急件或贵重物品的首选。本题目要求对航空货运管理系统进行类设计

（1）使用PowerDesigner绘制的类图

<1>核心类与功能

Product（产品类）：
记录产品属性（编号、ID、名称、尺寸、重量等），计算计费重量（chargeableWeight）（如体积重量与实际重量取大值，用于运费计算）。

Customer（客户类）：
记录客户信息（ID、姓名、电话、地址），用于订单中的寄件 / 收件人信息。

Order（订单类）：
包含订单基本信息（编号、日期）、寄件 / 收件信息（地址、姓名、电话），关联支付策略（PaymentStrategy）。
通过 pay() 方法调用支付策略的 pay()，实现订单支付。

Flight（航班类）：
记录航班信息（编号、起降机场、日期、最大载重）。

PaymentStrategy（支付策略接口）：
定义 pay() 方法，由 AliPayPayment（支付宝支付）和 WeChatPayment（微信支付） 实现，封装具体支付逻辑。
该接口体现了开闭原则，当支付方式有变化时，只需添加一个能实现PaymentStrategy（支付策略接口）的子类即可以实现代码的扩展，而不需要去修改过多的代码，体现了开闭原则和单一职责原则。

Calculate（费用计算类）：
提供 calculateTotalFee(List) 方法，计算产品列表的总费用（如根据计费重量和费率计算运费）。

<2>设计模式与关系

策略模式（PaymentStrategy）：
支付宝和微信支付作为具体策略，通过接口与订单解耦，允许运行时动态切换支付方式（如 Order 类可灵活设置 paymentStrategy 为 AliPay 或 WeChat）。

依赖关系：
Order 依赖 PaymentStrategy（通过属性关联），Main 依赖 Order、Calculate 等类，实现模块间的协作。
Calculate 处理 Product 列表，计算费用，为订单支付提供金额依据。

<3>心得

接口的运用使代码的扩展性和可读性得到了极大的提升，降低复杂度，新增支付方式只需实现 PaymentStrategy 接口。

（2）使用SourceMontor生成报表内容

<1>报表数据分析

代码行数共399行。（规模较大）。

Statements为15行，说明大部分的代码并没有实现，（比如一些get，set封装的方法并没有运用），但是良好的封装性有助于代码的维护和迭代。

代码的分支结构比例为6.7%，比较低，分支结构的减少有助于降低代码的耦合度。

方法调用次数为5次，说明代码调用次数较少，还在迭代的初级阶段。

代码的的注释率为0.8%，代码的注释行数太少，不易理解，如果太繁琐，可能会造成可读性差。但是写代码过程中总是忘记注释。

接口有两个，分别为微信支付接口和支付宝支付接口，这两个接口分别实现PaymentStrategy()接口中的Pay()方法。

每个类的方法数量平均数量为6.5个。方法较多，主要为封装起来所需要的get和set方法（这个所占的代码行数挺多的）。

最大复杂度为 0，且Name of Most Complex Method显示{no methods}，Line Number of Most Complex Method为{undefined} ，说明代码中没有复杂的方法，不存在高复杂度的逻辑。

代码块深度为 388，Maximum Block Depth为 3，Average Block Depth为 1.35 ，说明代码中最深的代码块深度为 3，平均深度为 1.35，代码块嵌套程度不高，结构相对扁平。

平均复杂度为 0.00，进一步表明整体代码复杂度低。

<2>心得

代码的注释可以多添加几条，提高可读性。可以省去一些没有调用实现的方法。这样可以使代码更加的整洁直观。

2，第二次航空货运管理系统程序

（1）使用PowerDesigner绘制的类图

<1>核心类与功能

支付策略（策略模式）：
PaymentStrategy接口定义支付行为（pay()）和支付方式名称（getMethodName()）。
具体实现类（WeChatPayment、CashPayment、AliPayPayment）封装不同支付逻辑，支持动态切换支付方式（如订单可灵活选择微信、现金或支付宝支付）。

客户（继承与多态）：
抽象类Customer定义通用属性（ID、姓名、电话、地址），子类CorporateCustomer（企业客户）和IndividualCustomer（个人客户）重写getCustomerType()（区分客户类型）和getDiscountRate()（计算折扣率，如企业客户可能有更高折扣），实现客户类型差异化处理。

产品（继承与多态）：
抽象类Product定义通用属性（ID、尺寸、重量、费率等），子类（NormalProduct、DangerousProduct、ExpeditedProduct）重写calculateRate()（如危险品费率更高，加急产品有特殊费率计算），实现产品类型差异化的费率逻辑。

订单与费用计算：
Order类关联支付策略（paymentStrategy），封装订单信息（寄件 / 收件详情、支付方式），通过pay()调用支付策略完成支付。
Calculate类提供费用计算逻辑：calculateTotalFee计算产品列表总费用（基于产品计费重量和费率），calculateTotalFeeWithDiscount结合客户折扣（如企业客户折扣）计算最终费用，支持动态折扣规则。

航班与物流：
Flight类记录航班信息（编号、起降机场、日期、最大载重），可用于校验订单产品重量是否超过航班载重限制（类图中未显式关联，需补充物流校验逻辑）。

程序入口（Main类）：
作为系统入口，main方法协调业务流程（如创建订单、选择支付策略、计算费用），createProduct方法通过简单工厂模式根据产品类型（普通、危险品、加急）。

<2>设计模式与关系

策略模式（支付）：通过接口，允许运行时切换（如订单支付可灵活选择微信、支付宝等），符合开闭原则。

继承与多态（客户、产品）：抽象基类定义通用行为，子类扩展差异化逻辑（如客户折扣、产品费率），提高代码复用性和扩展性。

简单工厂（Main.createProduct）：集中产品创建逻辑，降低客户端与具体产品类的耦合（如新增产品类型只需修改工厂方法，无需修改调用方）。

依赖关联：
Order依赖PaymentStrategy（支付策略）、Product（订单商品）、Customer（寄件 / 收件人，类图中属性重复，建议直接关联Customer对象优化）。
Calculate依赖Product（计算费用）和Customer（应用折扣），实现费用计算的模块化。

<3>心得

在这个类图中我首先想的是如何完成这个系统操作，因为第二次的迭代，顾客和商品都发生了很大的变化。顾客变为了两类，商品变为了两类，但是他们的作用或者需要实现的功能并没有变化。所以我就想的是将顾客和商品分别作为一个抽象父类，然后两种不同的顾客分别继承顾客父类，三种不同的商品分别继承商品父类。然后接口的方便这时候就体现出来了，只需要再添加一个现金支付就可以了。这也让我拥有了简单工厂的思维。

（2）使用SourceMontor生成报表内容

<1>报表数据分析

代码行数（Lines）：434 行，算为较大规模。

语句数（Statements）：194 条，占行数的～44.7%（194/434），代码密度中等。

分支语句占比（Percent Branch Statements）：16.0%，说明条件逻辑（如 if、switch）较少，代码时效性较低。

方法调用（Method Call Statements）：34 次，方法间交互较少，可能存在代码复用不足。

注释占比（Percent Lines with Comments）：3.5%，注释严重不足，影响代码可读性和维护性。

类与接口（Classes and Interfaces）：7 个，类 / 接口数量适中，但平均每个类的方法数（Methods per Class）为 13.14，耦合度太高，较为复杂。

最深块行号（Line Number of Deepest Block）：415 行，最大块深度（Maximum Block Depth）为 6，说明存在多层嵌套逻辑（如 if-else 或循环嵌套），可能导致代码可读性差、维护困难。

平均块深度（Average Block Depth）：1.50，整体嵌套较浅，仅局部（深度 6）需优化。

<2>心得

增加注释，提升代码可读性，尤其是复杂逻辑和关键方法。还有那种特别长的代码，我需要优化以下，拆分一下。

三，踩坑心得

<1> 在写第一次题目集时，长时间卡在前三个正确测试的测试点，微信输出金额输出总是错误，后面发现不管实际重量和体积重量哪个大，总是使用体积重量，但这是错的第一个原因，另一个时输入中并没有选择支付方式，只是在输出中直接采用的微信支付，所以我就将微信支付作为默认的支付方式。

<2> 第二次题目集中客户的类型和商品的种类都是通过输入英文来选择，中文不行。

四，改进建议

<1>增加注释：提升代码可读性，尤其是复杂逻辑和关键方法。

<2>拆分臃肿类：将方法数过多的类按职责拆分，降低耦合度（遵循单一职责原则）。

<3>代码清理：删除无意义的空行或冗余结构

<4>可以将输出再做成一个类，这样Main类中就不会显得这么臃肿，也能更好的体现分工，模块化，更加紧密。

五，总结

通过本次题目集我学到了接口和抽象父类（继承与多态）的用法，以及单一职责和开闭原则，和一些基础的工厂概念。也学到了构造合适类的重要性，合适的类就是我们在编写代码时正确的方向，沉下心来认真思考一定能学会这些知识。