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

本篇文章分享面向对象编程前三次大作业总结，对你有帮助的话记得收藏一下，看Java资料网收获更多编程知识

前言

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

• 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：单部电梯增强调度

类图设计

源码分析要点

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

• 调度算法逻辑问题
  在hasRequestsInDirection方法中，条件elevator.getCurrentFloor() == req.getFloor()可能逻辑不正确，电梯当前楼层等于请求楼层时应该直接处理

• 方法复杂度依然偏高
  determineDirection()和hasRequestsInDirection()`方法逻辑较复杂。

• 缺少输入解析层

分析报告

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

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

复杂度问题：

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

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

类图设计

源码分析要点

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

分析报告

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

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

复杂度问题：

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

踩坑心得

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

改进建议

可以针对架构设计、复杂度控制等方面进行改进，详细的前面已注明，不再多说。

总结

收获与成长

通过本阶段的练习，我能够学会如何设计类以及合理进行职责划分，并且能从只关注功能到关注复杂度、覆盖率，学习了迭代优化思维，能够通过持续重构改善代码质量。

文章来源:https://www.cnblogs.com/lrx0918/p/19255745
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！