三次电梯题目没写出来转生写博客

一.前言
在 Java 面向对象编程的学习进程中，电梯调度程序系列题目构成了一段极具挑战性的实践之旅。这组由三道题目组成的任务，以阶梯式难度层层递进，从基础的单类设计逐步延伸至多类协同的复杂架构，全方位检验了对类设计、数据结构运用和算法逻辑实现等多方面的知识掌握。
题目深度融合了多项核心编程要素。面向对象编程思想贯穿始终，要求在类的设计中遵循单一职责原则，合理划分电梯类、乘客类、队列类等角色的职责，实现高内聚低耦合。数据结构的选择与应用在请求队列管理中至关重要，需处理请求的先进先出、重复与无效请求筛选等问题。而电梯运行规则的算法设计，如优先处理同向请求、顺路响应等逻辑，则考验着条件判断与流程控制的严密性。
实践过程中，遇到了诸多技术难点。初期将外部请求转换为内部队列时出现的时序错误，导致电梯产生 “空跑” 现象；楼层越界校验的缺失，也使程序在异常输入下难以稳定运行。这些问题反映出在复杂逻辑处理和边界条件考虑上的不足。尽管最终未能完整实现所有题目要求，但在反复调试、优化代码的过程中，逐步加深了对编程原理的理解，积累了处理实际问题的宝贵经验。
此次实践经历，不仅是对编程能力的一次检验，更是探索技术深度的契机。每一次尝试与思考，都为后续的学习奠定了基础，也让我更加清晰地认识到持续精进的方向。
上述前言客观呈现学习中的挑战与收获。若你觉得某些内容需要增减，或想调整表述风格，随时和我说。

二.设计和分析

第一次题目看到我十分的懵逼,不知道从何下手,整个人都懵了。题目里又是电梯各种属性，又是复杂的运行规则，光看文字描述就觉得特别混乱。请求队列要分上行和下行，还要优先处理同方向请求，完全不知道该怎么用代码实现。

对着输入输出样例研究半天，还是一头雾水。不知道怎么写代码接收用户输入，也不知道怎么判断请求是不是无效。更别提设计电梯类，把状态管理、请求处理这些功能都实现出来了。当时心里特别慌，感觉自己学的Java知识根本不够用，完全不知道该从哪里开始写代码。

第一次作业我因为完全没搞懂题目而没有得分,以下是我的代码分析:
Lines：文件有 131 行代码，属于规模相对较小的文件，但代码行数少不代表逻辑简单，仍可能存在复杂逻辑 。
Statements：共 77 条语句，平均每行语句数不算多，不过语句的具体类型（如赋值语句、条件语句等）对代码复杂度和执行效率影响较大 。
Percent Branch Statements：分支语句占比 20.8% ，意味着代码中存在一定量的条件判断逻辑，如 if - else、switch 等，这会使代码逻辑变得复杂，测试时需考虑不同分支情况 。
Method Call Statements：有 47 条方法调用语句，说明代码中方法调用频繁，合理的方法调用可提升代码复用性，但也需关注方法间的耦合度 。
Percent Lines with Comments：注释行占比为 0.0% ，完全没有注释会极大降低代码可读性和可维护性，无论是自己后续回顾还是他人接手，理解代码都会很困难 。
Classes and Interfaces：仅有 2 个类，说明代码结构相对简单，类间关系不复杂，但也可能存在单个类承担过多功能的问题 。
Methods per Class：平均每个类有 2.00 个方法，方法数量较少，每个类的职责或许相对单一，但也可能意味着功能划分不够细致 。
Average Statements per Method：每个方法平均有 16.25 条语句，方法长度适中，但语句具体功能和逻辑复杂度还需进一步分析 。
Line Number of Most Complex Method：最复杂方法在第 17 行，该方法为 Main.findNextRequest () ，可针对性地对这部分代码进行审查和优化 。
Maximum Complexity：最大复杂度为 14，说明该方法逻辑较为复杂，理解、调试和维护难度大，可能需要重构 。
Line Number of Deepest Block：最深块深度在第 121 行，达到 7 ，多层嵌套结构会降低代码可读性和可维护性，修改时易出错 。
Maximum Block Depth：最大块深度为 7 ，进一步表明代码中存在深度嵌套情况，需关注逻辑合理性和可优化空间 。
Average Block Depth：平均块深度为 3.09 ，整体上反映代码中代码块的嵌套程度处于一定水平，可能影响代码执行效率和理解难度 。
Average Complexity：平均复杂度为 9.67 ，说明代码整体复杂程度较高，后续维护和扩展需格外小心 。
我想从这些指标综合来看，代码结构简单但复杂度较高，缺乏注释影响可读性，复杂方法和深嵌套结构可能是导致运行超时的潜在因素，需要针对性优化。

所以第一次遇到大作业,没看清题目,一直瞎做

类图

这次有了经验,经过代码迭代,虽然正常输出,可始终通过不了测试点

总结:
Lines：代码行数为 301 行，规模相对适中，但代码质量和复杂度不能仅由行数判断 。
Statements：有 174 条语句 ，语句数量较多，代码逻辑可能比较丰富，不同类型语句（如条件、循环语句等）会影响代码复杂度 。
Percent Branch Statements：分支语句占比 16.7% ，说明代码里有一定数量的条件判断逻辑，像 if - else、switch 等语句，会让代码逻辑判断变复杂，测试时得考虑各种分支情况 。
Method Call Statements：方法调用语句有 89 条 ，方法调用频繁，合理调用能提升代码复用性，但要注意方法间的耦合度，别过度关联 。
Percent Lines with Comments：注释行占比 2.7% ，注释太少，代码可读性和可维护性差，自己以后回顾或者别人接手维护都困难 。
Classes and Interfaces：有 2 个类 ，类的数量少，代码结构相对简单，但可能单个类承担功能过多，不符合高内聚低耦合原则 。
Methods per Class：平均每个类有 19.50 个方法 ，方法数量较多，可能功能划分较细，但也可能存在方法职责不清晰的问题 。
Average Statements per Method：每个方法平均有 4.26 条语句 ，方法语句不算多，不过方法功能和逻辑复杂程度还得具体分析 。
Line Number of Most Complex Method：最复杂方法在第 190 行 ，这个方法是 Main.main () ，是程序入口方法，它复杂可能会影响整个程序的理解和维护 。
Name of Most Complex Method：最复杂方法是 Main.main () ，意味着程序入口逻辑复杂，可能包含很多程序初始化、业务逻辑调用等操作 。
Maximum Complexity：最大复杂度为 8 ，说明代码中存在较复杂逻辑，理解、调试和优化难度较大，可能要考虑重构 。
Line Number of Deepest Block：最深块深度在第 281 行 ，达到 6 ，代码块嵌套层数多，会降低代码可读性和可维护性，修改代码容易出错 。
Maximum Block Depth：最大块深度是 6 ，进一步表明代码存在深度嵌套，要关注逻辑合理性和优化空间 。
Average Block Depth：平均块深度为 1.28 ，反映出代码整体的嵌套程度不算特别高，但仍需注意局部深度嵌套问题 。
Average Complexity：平均复杂度为 8.00 ，说明代码整体复杂程度较高，后续修改和扩展要小心，防止引入新问题 。
整体而言，代码存在注释少、主方法复杂、嵌套深等问题，这些可能影响代码质量和运行效率，是后续优化重点方向。
虽然正常输出但是不能通过测试点,到试运行超时,我也找不到办法,测试点也太少了,没通过就是没通过,就是没有分数
接下来是第三次电梯调度

类图

第三次迭代让我更是懵逼,还有这个类图更复杂了
越写越写不来
这次更是编译错误了

Project Name：项目名称显示为乱码（ÉÇȏ ），可能是编码问题，这在团队协作或项目管理中可能带来识别和沟通障碍，需检查和修正编码 。
Checkpoint Name：检查点名称是 Baseline ，可用于标识项目特定阶段状态，方便版本管理和回溯对比 。
File Name：文件名是 Main.java ，作为 Java 程序主文件，程序入口 main 方法大概率在此文件中 。
Lines：代码行数为 317 行 ，规模适中，但代码复杂度不能仅依据行数判断，还需结合逻辑等因素 。
Statements：有 182 条语句 ，语句数量较多意味着代码逻辑相对丰富，不同语句类型（如条件、循环等）影响代码复杂度 。
Percent Branch Statements：分支语句占比 13.7% ，说明代码中存在一定量条件判断逻辑（如 if - else、switch 等），会使逻辑判断变复杂，测试时需考虑多种分支情况 。
Method Call Statements：方法调用语句有 70 条 ，方法调用较频繁，合理调用可提升代码复用性，但需关注方法间耦合度，避免过度关联 。
Percent Lines with Comments：注释行占比 2.8% ，注释过少，极大降低代码可读性和可维护性，无论是自己后续回顾还是他人接手维护都较为困难 。
Classes and Interfaces：有 2 个类 ，类数量较少，代码结构相对简单，但可能存在单个类承担功能过多、职责不够清晰的问题 。
Methods per Class：平均每个类有 20.50 个方法 ，方法数量较多，可能功能划分较细，但也可能导致方法职责混乱，需进一步审视 。
Average Statements per Method：每个方法平均有 4.22 条语句 ，方法语句数量不算多，但具体功能和逻辑复杂程度仍需深入分析 。
Line Number of Most Complex Method：最复杂方法在第 188 行 ，且最复杂方法是 Main.main () ，作为程序入口方法，其复杂性会对整个程序的理解、调试和维护产生较大影响 。
Name of Most Complex Method：最复杂方法为 Main.main () ，说明程序入口处逻辑复杂，可能涉及大量初始化、业务逻辑调用等操作 。
Maximum Complexity：最大复杂度为 6 ，表明代码中存在一定复杂逻辑，理解、调试和优化存在一定难度，必要时可考虑重构 。
Line Number of Deepest Block：最深块深度在第 297 行 ，达到 5 ，代码块存在一定层数的嵌套，会降低代码可读性和可维护性，修改时易出错 。
Maximum Block Depth：最大块深度是 5 ，进一步说明代码存在一定深度的嵌套结构，需关注逻辑合理性和优化空间 。
Average Block Depth：平均块深度为 1.36 ，反映出代码整体嵌套程度不算特别高，但仍需留意局部深度嵌套带来的问题 。
Average Complexity：平均复杂度为 6.00 ，说明代码整体具有一定复杂程度，后续修改和扩展时需谨慎操作，防止引入新问题 。
总体而言，该代码存在注释稀缺、主方法复杂、嵌套结构等问题，这些都可能对代码质量和运行效率产生负面影响，是后续优化的关键方向。

失败心得:
第一次大作业算是彻底搞砸了，心里真不是滋味。现在回头想想，自己的问题实在太多了。
刚看到作业题，我就懵了。那么多要求，那么复杂的任务，我一下子就慌了神。也不想想怎么去分析题目，怎么把问题拆开解决，就知道在那干着急。在网上搜了一堆代码，也不管适不适用，直接往自己的作业里塞，想着说不定就能蒙混过关。现在才明白，这种盲目瞎搞根本没用，纯粹是浪费时间。
遇到难的地方，我就只会抓头。盯着题目半天，脑子却一片空白，越着急越想不出来。我也没想过翻翻书，看看之前学的知识能不能解决问题，或者去问问同学老师。就自己在那干耗着，耗到最后，还是啥都没写出来。
还有就是拖延的毛病。作业刚布置的时候，我总觉得时间还长呢，不着急。今天拖明天，明天拖后天，结果一眨眼就快到截止日期了。这时候才开始慌，可时间根本不够用了。
这次作业的失败，真给我狠狠上了一课。下次作业，我可不能再这么瞎搞了。拿到题目，我得先好好看看，把要求弄清楚，一步一步地规划好怎么去做。遇到难题，我不能再干瞪眼，得主动想办法，该查资料查资料，该问人问人。
还有拖延这个坏毛病，必须得改。作业一布置下来，我就开始动手，每天都完成一点，绝不再拖到最后。我相信只要我认真去做，一步一个脚印，肯定能把作业完成好。
这次的经历虽然糟心，但也让我知道自己错在哪了。以后学习，我可得长点心，不能再这么糊涂了。

改进建议
对于电梯调度程序代码的改进建议，主要可以从遵循单一职责原则、提高代码可读性、优化算法逻辑和增强代码健壮性等方面进行：
类结构与职责分离
进一步明确类职责：目前虽然有不同功能的类，但类之间的职责边界可以更加清晰。例如，RequestQueue 类目前同时管理外部请求队列和内部请求队列，可以考虑拆分成 ExternalRequestQueue 和 InternalRequestQueue 两个类，分别负责外部乘客请求和内部乘客请求的管理，这样职责更加单一，代码也更易于理解和维护。
提取公共逻辑：在 Elevator 类和 Controller 类中，有一些逻辑可以提取成更细粒度的方法。比如在 Elevator 类的 moveToFloor 方法中处理外部请求和内部请求的逻辑，可以分别提取成 processExternalRequest 和 processInternalRequest 方法，使 moveToFloor 方法更加简洁明了。
提高代码可读性
增加注释：目前代码的注释比例较低，应在关键方法、变量和复杂逻辑处添加注释。例如，在 Controller 类的 findNextFloor 方法中，对于复杂的查找逻辑添加注释，解释每一步的目的和作用，方便其他开发者理解代码意图。
优化算法逻辑
减少循环嵌套和复杂度：Controller 类的 findNextFloor 方法中存在较多的循环嵌套，导致方法复杂度较高（Main.main() 方法复杂度也较高）。可以尝试使用更高效的数据结构或算法来简化查找逻辑，降低时间复杂度。例如，可以使用 TreeSet 等有序数据结构来存储请求，以便更快速地查找符合条件的请求楼层。
提前处理无效请求：在读取用户输入时，可以在 Main 类中提前处理无效请求（如楼层超出范围等），避免无效请求进入请求队列，减少后续处理的复杂性。
提取通用方法：将一些通用的功能方法提取出来，以便在不同的类中复用。例如，判断楼层是否有效的方法可以提取到一个工具类中，供 Elevator 类和 Main 类等使用。

总结
在这完成这三次题目后，我再次认识到遵循单一职责原则的重要性，对于类之间的各种调用关系的了解与应用更加深刻与熟练。
但我同时也需要更多的去练习类的设计与类之间的调用，在各次作业中，我都是跟据题目给出的类图来进行编程，难以通过自身的能力去设计类与类之间的关系。