面向对象编程前三次大作业总结

前言

本次大作业是第一个面向对象编程的实操练习，难度从中到难，层层递进。

OOP题目集01
大部分是作为前面Java程序练习的过渡用的练习题，题目简单，题型常见不复杂，能帮助我们学习更多方法运用于Java编程当中。
第一次电梯调度程序也是基础的电梯类设计，初步了解题目的需求，为以后的迭代设计奠定基础。
OOP题目集02
本次题目集对类设计有了更严格的要求标准，题目复杂度逐渐上升，涉及类的创建和使用，能够更好地加深面向对象编程思想。
第二次电梯调度程序在第一次的基础上进行了迭代涉及，了解单一职责原则。
OOP题目集03
本题目集需要解决更深层次的应用，涉及到类的继承等等。
这次的电梯调度程序则进一步开始迭代性设计。

设计与分析

由于能力上的不足等原因，有关单部电梯调度的程序未能成功调通（或未完成），故在此主要分析我代码上的缺陷不足和问题所在。

题目集1：单部电梯基础调度

类图设计

源码分析要点

首先，编译并运行之后显而易见的出现了错误：运行时错误，会一直循环打印，并且楼层数量始终为0，显然出现了很多逻辑错误。
这边是用ai工具分析的情况：

逻辑混乱
在Main类中，使用字符串长度（input.length()>=3&&input.length()<6）来区分内部和外部请求不可靠。例如，外部请求<10,UP>长度为7，会被错误分类；内部请求如100（3字符）可能被误判为外部请求。
改进建议：最好使用正则表达式或解析请求内容来区分类型
数据封装不足，违反OOP原则
Elevator类的字段（如IQ、OQ）被声明为public，并在Main类中直接访问（例如elevator.OQ.add(input)），破坏了封装性。
改进建议：将字段设为private，并通过公共方法（addRequest(String request)）来添加请求，内部根据请求类型自动分类

分析报告

报告显示：
代码质量指标：

分支覆盖率：27.6% - 测试覆盖率较低
注释率：21.7% - 注释相对充分
方法复杂度：平均每个方法7.06条语句

复杂度问题：

最大圈复杂度：4（标有*号，表示有方法较复杂）
平均复杂度：1.85（标有*号，超出理想范围）
最大嵌套深度：4层

题目集2：单部电梯增强调度

类图设计

deepseek_mermaid_20251122_af78b9

源码分析要点

由于时间问题，我并没有完成最后的代码，因此以下是使用ai工具分析其他代码部分的结果：

调度算法逻辑问题
在hasRequestsInDirection方法中，条件elevator.getCurrentFloor() == req.getFloor()可能逻辑不正确，电梯当前楼层等于请求楼层时应该直接处理
方法复杂度依然偏高
determineDirection()和hasRequestsInDirection()`方法逻辑较复杂。
缺少输入解析层

分析报告

报告显示：
代码质量指标：

分支覆盖率：17.8% - 测试覆盖率下降
注释率：9.3% - 注释比例减少
方法复杂度：3.10 - 方法规模明显减小

复杂度问题：

最大圈复杂度：4（标有*号，表示有方法较复杂）
平均复杂度：1.14（标有*号，但相比第一次的1.85显著降低）
最大嵌套深度：4层
平均嵌套深度：1.41层

题目集3：单部电梯优化调度

类图设计

deepseek_mermaid_20251122_9d724a

源码分析要点

重复请求过滤不完整
虽然内部请求有去重，但外部请求没有。
楼层有效性检查缺失
添加请求时没有检查楼层是否在有效范围内。
方向匹配逻辑可以优化
在shouldStop和removeRequests中重复了相似的方向检查逻辑。
硬编码的初始输出
Main类中硬编码了初始方向输出。

分析报告

报告显示：
代码质量指标：

分支覆盖率：22.3% - 测试覆盖率有所改善，但仍偏低
注释率：22.3%

复杂度问题：

最大圈复杂度：3
平均复杂度：1.54（相比第二版的1.14有所上升）
最大嵌套深度：6层
平均嵌套深度：1.85层

踩坑心得

第一次设计最大的问题就是逻辑混乱复杂，所有功能都往一个类装，调度逻辑、状态管理、队列处理混杂在一起。
第二次有了参考类图设计，结构方面稍微改善了点，但由于第一次未能打好基础，所以第二次也没有成功写出完整的程序。
第三次终于能正常运行了，但依然存在答案错误，未通过测试点的问题，这说明我在新增功能时没有同步增加测试，而且嵌套深度过深，条件判断过于复杂了。
随着程序的复杂度上升，应在注释方面多注意，方便未来调试。