第二次Blog作业-航空货运管理系统
在第8-9次作业中，我分别利用类设计以及继承与多态实现了航空货运管理系统，第二次作业在第一次作业的基础上进行了迭代，功能更加的完善，类与类之间的关系更加明确
，同时第二次实验更能满足编程的原则：开闭原则，单一职责原则；这两次作业我都用我自己的方法拿到了100分，下面我将分享我的实验心得与做法。
前言：
知识点：
第一次实验ArrayList的使用，信息的遍历，
第二次实验：继承与多态，抽象类的构架 ；
题量：
这两次的题量相差不大，第二次是在第一次的基础上完善的，所以还是第一次的相对较大；
难度：
第二次的难度相对较难，第一次所运用的知识没那么多；
Complexity Metrics（复杂度分析）
因为下面要用到复杂度分析，所以先在此给出一些相关概念。
我们需要使用的主要是方法和类的复杂度分析。
方法的复杂度分析主要基于循环复杂度的计算。循环复杂度是一种表示程序复杂度的软件度量，由程序流程图中的“基础路径”数量得来。
ev(G)：即Essentail Complexity，用来表示一个方法的结构化程度，范围在[1,v(G)]之间，值越大则程序的结构越“病态”，其计算过程和图的“缩点”有关。
iv(G)：即Design Complexity，用来表示一个方法和他所调用的其他方法的紧密程度，范围也在[1,v(G)]之间，值越大联系越紧密。
v(G)：即循环复杂度，可以理解为穷尽程序流程每一条路径所需要的试验次数。
对于类，有OCavg和WMC两个项目，分别代表类的方法的平均循环复杂度和总循环复杂度。
下面我将从程序结构，公测、互测以及bug分析几个方面来总结我这两次次作业。
第一次实验
作业要求：
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开闭原则以及合成复用原则、依赖倒转原则，除需要在PTA平台提交源码外，还
需要在超星平台提交本次作业最终得分源码（首次提交最高分源码）的类图，
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载
重量）
2
客户填写货运订单并进行支付，需要提供如下信息：
客户信息（姓名，电话号码等）
货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
支付方式（支付宝支付、微信支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独
计费
代码规模
实验类图：
实验的详情：
Kiviat Graph（雷达图）：展示代码的多个维度指标，包括平均复杂度（Avg Complexity）、平均深度（Avg Depth）、最大深度（Max Depth）、最大复杂度（Max Complexity）、平均每个方法的语句数（Avg Stmts/Method）、每个类的方法数（Methods/Class）、注释占比（% Comments ）。
Block Histogram（柱状图）：横坐标是深度（从 0 到 9+ ），纵坐标是语句数，体现不同深度下的语句分布情况，深度为 2 时语句数最多 。 这些信息可帮助开发者了解代码的结构复杂度、代码规模等，以便进行代码优化、维护等工作。
第二次实验
作业要求：
本题需要对客户、支付方式以及货物类型进行泛化处理（继承），否则本题不得分
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开闭原则以及合成复用原则、依赖倒转原则，除需要在PTA平台提交源码外，还
需要在超星平台提交本次作业最终得分源码（首次提交最高分源码）的类图，
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载
重量）
2
客户填写货运订单并进行支付，需要提供如下信息：
客户信息（姓名，电话号码等）
货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
支付方式（支付宝支付、微信支付、现金支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独计费
代码规模
代码的类图：
复杂程度：
项目规模：291 行代码，188 条语句，属于中小型 Java 程序。
类密度：8 个类 / 接口，平均每个类 5.25 个方法，结构较为紧凑。
注释缺失：注释行占比 0.0%，可能影响代码可维护性和团队协作效率。
2. 复杂度分析
雷达图（Kiviat Graph）
平均复杂度（Avg Complexity）：较低（推测在 2-3 左右，需结合行业标准），表明多数方法逻辑简单。
最大复杂度（Max Complexity）：7（位于 Main.main() 方法），可能存在嵌套条件或循环。
平均深度（Avg Depth） 和 最大深度（Max Depth）：反映代码嵌套层级，需结合柱状图进一步分析。
柱状图（Block Histogram）
深度分布：
深度 2：语句数最多，可能是常见的方法调用或单层循环。
深度≥5：语句数显著减少，表明复杂嵌套逻辑较少。
潜在问题：若某深度层级语句过于集中，可能暗示代码结构不合理（例如过深的条件嵌套）。
3. 方法与语句分析
方法规模：平均每个方法 2.76 条语句，说明方法粒度较细，符合单一职责原则。
最复杂方法：Main.main() 复杂度为 7，可能包含程序入口的初始化逻辑或条件判断。需检查是否违反单一职责原则。
分支语句占比：6.9%，表明条件逻辑较少，代码可能以顺序执行或简单条件为主。
4. 潜在问题与优化建议
- 注释缺失
影响：无注释可能导致后续维护困难，尤其对新开发者。
建议：至少添加类注释（功能说明）和关键方法注释（参数 / 返回值 / 逻辑）。 - 主方法复杂度
风险：Main.main() 复杂度为 7，可能包含过多初始化或业务逻辑。
建议：将初始化逻辑拆分到独立的静态方法或配置类中，降低 main() 方法复杂度。 - 深度分布优化
检查点：确认深度 2 处的密集语句是否存在重复代码或可提取的公共逻辑。
重构方向：使用方法提取或设计模式（如工厂模式、策略模式）简化嵌套逻辑。 - 测试覆盖
数据不足：当前指标未提及测试覆盖率，但低复杂度代码通常更易测试。
建议：针对 main() 方法和核心逻辑编写单元测试，确保功能正确性。 - 与行业标准对比
复杂度参考：
方法复杂度通常建议控制在 5 以下（Cyclomatic Complexity 标准）。
平均每个方法语句数：理想范围为 5-15 条（视语言和场景而定）。
改进空间：虽然 Main.java 的平均复杂度较低，但 main() 方法仍需优化以符合行业标准。 - 总结
整体结构良好，方法粒度细且复杂度可控，但存在注释缺失和主方法复杂度略高的问题。建议优先补充必要注释，并对 main() 方法进行逻辑拆分，以提高代码的可维护性和可扩展性。
![]()
![]()
三，踩坑心得：
1.对于信息便利不太会，太多内容，没有规律，
客户类型[可输入项：Individual/Corporate]
客户编号
客户姓名
客户电话
客户地址
货物类型[可输入项：Normal/Expedite/Dangerous]
运送货物数量
[货物编号
货物名称
货物宽度
货物长度
货物高度
货物重量
]//[]内的内容输入次数取决于“运送货物数量”，输入不包含“[]”
航班号
航班起飞机场
航班降落机场
航班日期（格式为YYYY-MM-DD）
航班最大载重量
订单编号
订单日期（格式为YYYY-MM-DD）
发件人地址
发件人姓名
发件人电话
收件人地址
收件人姓名
收件人电话
支付方式[可输入项：Wechat/ALiPay/Cash]
2.类与类之间的关系搞不明白：
3.double n;
String category = menu.get(0);
if(category.compareTo("Individual")==0){
n = 0.9;
}else{
n = 0.8;
}一开始我是在else-if内声明n的但是出现错误，显示n没有定义，之后我将n拿到外面进行声明。
4.输出格式问题明细编号 货物名称 计费重量 计费费率 应交运费
1 发电机 80.0 40.0 3200.0
2 信号发生器 45.0 50.0 2250.0
我一直用空格进行分割，但是并没有达到题目目的，之后我了解了“/t”是处理格式的符号。
改进建议
补充代码注释：
对类功能、关键方法参数 / 逻辑添加注释（如Customer类职责、calculateFee方法计费规则），提升可维护性。
重构主方法：
将Main.main()中的初始化逻辑（如航班、订单创建）拆分到独立工具类（如DataLoader），降低复杂度至行业建议的 5 以下。
优化输入输出处理：
封装输入校验逻辑（如日期格式、枚举类型检查）到独立方法，避免重复代码；使用String.format()精准控制输出格式（如固定列宽），减少硬编码空格。
增强扩展性：
为货物类型、支付方式预留抽象接口，便于后续新增类型时通过继承扩展，进一步体现开闭原则。
单元测试覆盖：
对核心计费逻辑、订单状态计算等方法编写测试用例，确保业务逻辑正确性。
总结
两次作业通过类设计、继承与多态实现了航空货运系统的迭代优化，均达成功能目标并获满分。第一次聚焦单一职责与基础类设计，第二次通过抽象类、多态拓展支付方式和货物类型，更贴合开闭原则。代码结构紧凑，方法粒度合理，但存在注释缺失、主方法复杂度偏高及输出格式调试耗时等问题。踩坑过程中掌握了ArrayList遍历技巧、类间关系设计及\t格式控制，对面向对象设计原则有了更深入理解。
浙公网安备 33010602011771号