第二次迭代作业博客
第一部分 前言
题目集8-9以航空货运管理系统问题为中心对其中的订单获取及显示程序进行了两次编程迭代。
在第一次迭代问题的考察基础上,本次迭代作业进一步考察了面向对象编程的核心概念如复杂类及类间关系,面向对象编程的三大核心技术—继承、多态、封装,常用的面向对象设计模式如策略模式,并依据此次迭代要求重点体现了抽象类的运用以及继承与多态的联系。同时我依据平日的学习内容适当运用体现了容器类、流式输出和格式化输出等Java常用的类以及语言特性。
本次两个题目集对应四次知识点巩固练习及一次二轮迭代练习,总体上题量适中,在保证对此阶段学习的知识的巩固和能力提升的同时,也考虑到同学的日常学习时间分配。而针对巩固练习和迭代练习本身,其难度符合目前学习阶段大多数学生的学习能力巩固和提升及考察要求,比较合理。
第二部分 设计与分析
一. 第一次迭代设计及分析
- 作业要求
模拟某客户到该航空公司办理一次货运业务的过程。
2.类图设计

在该类图中,Main为主类;Pay Method为支付抽象类,ZhiFuBaoPay、WeiXinPay为Pay Method支付具体类(继承);Plane为航班类;Consumer为乘客类;Goods为单一货物类;Order Message为订单信息类;Agent为中介类。
分析:第一次迭代问题涉及类图总体上符合题目要求并尽可能对对象进行拆分实现,但依然存在类间关系方面在实际问题中的不明晰与混乱,如对于对象货物和订单来说,应存在订单处理所有需求货物的信息以及其上有一个类对这些已形成订单的统一管理和信息显示会更加合理并符合实际问题情况。
3.当前实现代码问题层面分析


对于当前迭代实现代码的结构中同时也存在着较多的细节和问题,在此基础上进行代码结构分析:
a.代码细节:第一次迭代代码总行数共515行,包括主类在内共9个类,基本涵盖第一次迭代作业题设要求。
b.复杂度分析:程序最大复杂度为1,只涉及到单一条件的判断逻辑,无嵌套分支或循环,代码结构简单;程序平均复杂度为1。整段代码所有类均只涉及到简单的单一条件判断,并没有产生多条件的判断逻辑(这可能是由于对类间关系的协调或者职责拆分恰当),说明整段代码逻辑高度简单,没有特别复杂的逻辑控制;整段代码最复杂的类方法为WeiXinPay(),但其复杂度主要由于语句数量和嵌套深度相较于其他类内方法较多,总体上该方法逻辑依然简单,功能单一,符合单一职责原则。
c.方法块深度分析:代码最大深度为2,原因是方法中存在二层嵌套(条件语句中嵌套了循环语句);平均深度为0.94,及整体代码大部分为单一结构,逻辑简单,便于后续理解和修改。
d.潜在问题和修改建议:注释量整体较少。注释量仅占整体代码量的极少部分,除对某些类的类型进行了解释和说明之外,对一些关键逻辑和方法并未做简单的说明和分析,会影响后期对程序的理解和维护成本,建议对关键逻辑(如支付逻辑WeiXinPay的pay()方法)增加注释;分支覆盖不足。整体程序的复杂度为1,整体深度为1,逻辑和结构简单,便于修改和理解,但同时一些关键逻辑和情况的功能可能在处理一些特殊情况时会显得僵化,建议在部分逻辑重新分析其存在的情况,适当引入分支结构以增强其健壮性。
4.代码运行结果


依据格式输入测试实例可以正确实现所有的测试点,程序的基本功能无误。
二. 第二次迭代设计及分析
1.作业要求
模拟某客户到该航空公司办理一次货运业务的过程。
2.类图设计

在该类图中,Main为主类;Pay Method为支付抽象类,ZhiFuBaoPay、WeiXinPay、CashPay为Pay Method支付具体类(继承);Plane为航班类;Consumer类为乘客抽象类,OnlyConsumer、TogetherConsumer为乘客具体类;Order为订单类;OrderDetail为订单明细类;Goods为货物抽象类,Danger Goods、Rush Goods、NormalGoods为货物具体类。
分析: 此次代码结构类设计相较于第一次迭代取消了中介类进行各个类之间属性的整合输出,并按照分析依据实际情况需求形成了“订单类-订单明细类”职责划分,更加符合单一职责原则和现实情况,降低了耦合性。同时依据迭代要求对乘客、支付方式、货物进行了种类的扩展,更好的实现了面向对象编程的开闭原则。
3.当前实现代码问题层面分析


对于当前迭代实现代码的结构中同时也存在着较多的细节和问题,在此基础上进行代码结构分析:
a.代码细节:第二次迭代作业代码总行数为931行,其中多由于对于格式的多次重复及getter和setter方法的重复书写,因而实际代码量在较为合理的范围内,并未严重出现重复造轮子的错误;包括主类在内共15个类,基本涵盖所有题目要求并尽可能对题目涉及对象进行合理的设计和拆分以更好适应单一职责原则和迪米特法则。
b.复杂度分析:最大复杂度为5,是由于在NormalGoods.calculateRate() 方法中存在多层条件分支(if-else语句和嵌套逻辑),后续需针对题目需求对其逻辑进行适当优化减少嵌套,避免局部过于复杂形成“长尾效应”;平均复杂度为1.15,说明程序中大部分方法逻辑简单,但少数方法复杂度较高,已形成长尾效应对程序性能造成较大影响。
(长尾效应(Long Tail Effect) 通常指系统中那些发生频率较低、但累积起来对整体性能或稳定性产生显著影响的现象。这些现象可能单独出现时不易察觉,但随着时间的推移或在特定场景下,其累积效应会导致明显的性能下降、延迟波动或资源耗尽等问题。)
c.方法块深度分析:
o 深度1:192条(54.2%),主要为单层逻辑;
o 深度2:136条(38.4%),存在嵌套逻辑;
o 无深度≥3的代码,嵌套控制较好。
• 平均块深度:1.31,接近单层结构,整体代码层次清晰。
d.潜在问题和修改建议: 注释严重缺失(注释率仅0.2%-0.3%),需强制关键方法(如NormalGoods.calculateRate())添加逻辑说明;分支覆盖不足(分支语句占比≤3.4%);高复杂度方法(如calculateRate()圈复杂度达5),需重构条件分支;类职责过载(类均含9.67个方法),建议按单一职责原则拆分功能模块。此外,需通过代码审查规范注释与复杂度标准,从而系统性提升可维护性、健壮性及扩展性。
4.代码运行结果


依据格式输入测试实例可以正确实现所有的测试点,程序的基本功能无误。
第三部分 纠错心得
通过分析两份迭代作业结构数据(Test4.txt与plane2.txt),发现代码质量的核心问题集中于注释缺失、分支逻辑不足、高复杂度方法和类设计不合理。注释率(0.2%-0.3%)的严重不足直接导致代码可读性差,维护成本高,例如NormalGoods.calculateRate()方法虽承担关键计费逻辑,却无任何说明,隐含参数越界或计算错误的风险。分支逻辑的匮乏(分支语句占比≤3.4%)则暴露了代码健壮性堪忧。高复杂度方法(如calculateRate()圈复杂度达5)和深度嵌套(Test4.txt中深度2的代码占比35%)进一步加剧维护难度,反映开发过程中对设计模式(如策略模式)的忽视。此外,类职责过载(如plane2.txt中类均含9.67个方法)违反单一职责原则,导致代码耦合度高,修改易引发连锁错误。这些问题根源在于开发流程中重功能实现轻代码质量,缺乏规范约束。
第四部分 改进与建议
针对上述问题,需从代码规范、程序整体结构设计两方面系统性改进。
代码规范:
强制关键方法(如支付、计费逻辑)添加注释,明确输入输出。引入输入校验逻辑。
架构设计:
重构高复杂度方法:将calculateRate()中的条件分支拆分为策略类(如RateCalculator),或运用低嵌套逻辑重构替代if-else链,降低圈复杂度至≤3。
拆分职责过载的类:按功能分离NormalGoods为RateCalculator、WeightValidator等独立模块,遵循单一职责原则。
通过策略模式优化分支逻辑、组合模式解耦类依赖,可显著提升代码可维护性与扩展性。例如,支付模块可抽象为PaymentStrategy接口,由WeiXinPay和ZhiFuBaoPay分别实现,避免硬编码分支。
第五部分 总结
当前代码的优势在于结构清晰(平均块深度1.31)和方法简单(平均4.02条语句/方法),但劣势集中于注释缺失、健壮性不足和局部高复杂度,长期可能引发维护危机。改进需:
优先修复calculateRate()的复杂度和注释问题,补充异常处理;
重构类设计,采用策略模式与组合模式降低耦合;
总而言之,此次迭代程序需从“功能优先”转向“质量优先”,综合考虑复杂度、注释率、测试覆盖率,最终,系统性改进将平衡代码简洁性与健壮性。
第六部分 附录(源码及运行结果截图)
- 第一次迭代
输入样例:
10001
郭靖
13807911234
南昌航空大学
2
101
发电机
80
60
40
80
102
信号发生器
55
70
60
45
MU1234
昌北国际机场
大兴国际机场
2025-04-22
1000
900001
2025-04-22
南昌大学
洪七公
18907912325
北京大学
黄药师
13607912546
运行结果:
![]()
![]()
- 第二次迭代
源码略
输入样例:
Corporate
10001
郭靖
13807911234
南昌航空大学
Expedite
2
101
发电机
80
60
40
80
102
信号发生器
55
70
60
45
MU1234
昌北国际机场
大兴国际机场
2025-04-22
1000
900001
2025-04-22
南昌大学
洪七公
18907912325
北京大学
黄药师
13607912546
ALiPay
运行结果:



