NCHU--OOP--BLOG1--电梯调度程序

题目集 5-7 电梯调度程序实践与反思

一、前言

    过去三周，我们完成了题目集 5-7 的编程任务。这三次作业均包含单部电梯调度程序相关题目，且呈现迭代式递进的特点：从题目集 5 中将所有功能耦合在单一Elevator类的基础实现，到题目集 6 通过类拆分优化职责划分，再到题目集 7 对外部请求格式的调整（将<number,direction>改为<number,targetFloor>） ，逐步引导我们深入理解面向对象编程。
    这些题目不仅是语法实践的载体，更是思维转变的契机 —— 帮助我们从 C 语言的过程式编程思维，向 Java 的类抽象、封装、解耦思维过渡。每道题目都充满挑战：从初期的代码臃肿、违背单一职责原则，到后期通过重构优化类设计，再到算法逻辑的反复打磨，我们在解决实际问题的过程中，强化了类设计、算法应用能力，更深刻体会到代码可维护性与扩展性的重要性

二、设计与分析

题目集5单部电梯调度问题分析

题目如下：

7-5 NCHU_单部电梯调度程序
分数 70
中等
作者 段喜龙
单位 南昌航空大学
设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例:
在这里给出一组输入。例如：

1
20
< 3,UP>
<5>
<6,DOWN>
<7>
<3>
end
输出样例:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
电梯运行过程详解.pdf

代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB

SourceMonitor报表分析

类图分析

分析与心得

在完成这道关于电梯调度题目的过程中，我经历了诸多挑战，也收获了宝贵的经验。下面从输入处理、算法设计以及代码质量分析等方面进行详细总结。

一、输入处理的曲折历程

初次处理输入时，由于对正则表达式的不熟悉，在编写 inputCheck 方法上花费了大量时间和精力。该方法的返回类型为 boolean，用于判断输入是否符合要求，符合则返回 true，否则返回 false。具体实现逻辑如下：

1. 使用正则表达式 ```java
   String regex = "<([^>]*)>";
   来判断输入字符串是否包含一对尖括号。
2. 利用 replaceAll 方法去除尖括号，接着依据字符串中是否存在逗号来区分内部请求和外部请求。
3. 对于内部请求，因为当时尚未学习 Integer 类（不知道其提供了直接转换为整型的方法），所以自行编写了 StringToInt 方法实现字符串到整型的转换；对于外部请求，则以逗号为分隔点进行切割，并逐一判断各部分是否符合要求。

在这个方法中，大量的 if-else 语句使得代码结构变得复杂，可读性较差。此外，在结束条件的判断上，由于没有仔细阅读题目，忽略了输入的结束条件 end 是忽略大小写的，错误地使用了 equals 方法进行判断，导致程序一直出现非零返回的情况。后来在 PTA 讨论区的启发下，将其修改为 equalsIgnoreCase 方法，才成功解决了这一问题。

二、算法设计的艰难突破

算法设计是本题最具挑战性的部分，我多次误解了题目的意思。比如在看到测试样例中，电梯在 5 楼时同时收到内部请求的 7 楼和外部请求的 6 楼，按照自己的理解，认为应该先处理距离较近的 6 楼请求，但实际结果却是先到 7 楼。这是因为我一直将现实生活中电梯的调度逻辑套用到程序中，忽略了题目中方向优先的原则。

在反复思考和尝试无果后，我参考了 PTA 讨论区里已经提交正确答案的同学的建议，仔细研究了老师发布的关于本题测试样例的分析。经过不断地调试和修改，终于在 4 月 1 日凌晨 1 点 10 分成功通过了所有测试点，那一刻内心充满了激动和成就感。

三、代码质量的深度剖析

通过 SourceMonitor 生成的代码分析报告，可以清晰地看出我提交的代码虽然通过了测试点，但在质量上存在不少问题：

• 代码规模方面：该文件总行数达到了 560 行，其中可执行语句有 241 条，分支语句占比 26.6%，方法调用语句为 78 条。这表明代码具有一定的体量和复杂程度，存在优化的空间。
• 代码质量层面：注释行仅占 16.2%，这意味着代码的可读性欠佳，后期维护时理解起来会有较大难度。文件中共有 2 个类和接口，平均每个类包含 9 个方法，每个方法平均有 4.94 条语句。这从侧面暗示了类的职责划分不够清晰，可能存在功能过于集中的问题，违背了单一职责原则（SRP）。
• 类设计角度：从类图来看，Elevator 类的设计十分不合理。在编写代码时，将所有的方法全部塞进了这个类中，严重不符合单一职责原则，这种设计也为下一次的题目集作业埋下了隐患。

此次经历让我深刻认识到，在编程过程中，不仅要实现功能，更要注重代码的规范性、可读性和可扩展性。未来，我将加强对设计原则的学习和应用，合理拆分类的职责，不断提升代码的质量。

![测试通过截图]

题目集6单部电梯调度问题分析

题目如下：

7-3 NCHU_单部电梯调度程序（类设计）
分数 50
较难
作者 段喜龙
单位 南昌航空大学
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段单类设计相同，但要处理如下情况：

乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>
注意：本次作业类设计必须符合如上要求（包含但不限于乘客请求类、电梯类、请求队列类及控制类，其中控制类专门负责电梯调度过程），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次电梯程序提交到本次题目中测试）。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：

1
20
< 3,UP>
<5>
<6,DOWN>
<7>
<3>
end
输出样例1:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
输入样例2:
在这里给出一组输入。例如：

1
20
< 3,UP>
< 3,UP>
<5>
<5>
<5>
<6,DOWN>
<7>
<7>
<3>
<22,DOWN>
<5,DOWN>
<30>
END
输出样例2:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB

SourceMonitor报表分析

类图分析

分析与心得

在基于上一次题目集完成本次任务的过程中，尽管电梯调度算法基本沿用，未做大幅改动，但在代码实现的细节和整体架构方面，我仍面临了诸多挑战，也积累了宝贵的经验。以下是对本次任务的详细总结。

一、算法与类结构的延续和改进

本次任务中，电梯调度算法保持不变，同时保留了电梯的一些关键属性，如最低楼层、最高楼层和当前楼层等。为了使代码结构更加清晰，我对部分元素进行了重新归类：

• 将 Direction、State 和 Queue 设置为电梯的属性，并将相关功能分散到不同的类中。
• 例如，新增了 Direction 枚举类来表示电梯的运行方向，State 枚举类来描述电梯的状态。
• 内部队列和外部队列则被整合到请求队列中，在对输入进行判断并分离内外部队列后，才对 RequestQueue 进行初始化操作。

二、功能实现中的问题与解决

（一）去重功能问题

在实现去重功能时，我由于粗心大意，误解了题目的要求。我最初简单地认为去重是针对所有相同的请求，而实际上题目要求的是相邻请求去重。这个错误导致我的代码始终无法通过一个测试点。在与室友深入讨论并仔细研读题目后，我才发现问题所在。修正去重方法后，代码顺利通过了所有测试点。

（二）类拆分后逻辑错误

此外，在完成类的拆分后，程序出现了逻辑错误。无论输入何种测试样例，程序的执行结果都与我在草稿纸上的推演大相径庭，例如本该执行内部请求时，却执行了外部请求。

为了找出问题根源，我借助 IDEA 的 debug 功能，逐步跟踪代码的执行过程，观察变量的变化情况。最终发现，这是由于在类拆分过程中，Direction 和 State 的数据类型从字符串变为枚举类型，但我在算法逻辑中仍使用原来的 equals 方法进行方向比较。由于枚举类型的比较规则与字符串不同，这种错误的比较方式导致 equals 方法始终返回 false，从而使程序无法执行正确的语句。

通过查阅相关资料，我找到了简单有效的解决办法：在调用 getDirection 方法时，再调用 ToString 方法进行类型转换，成功解决了这一问题。

三、代码规模的优化与反思

值得注意的是，上一次题目集的代码量为 560 行，而本次经过类的拆分后，代码量增加到了 600 多行，这导致代码无法提交，出现了代码过长的提示。

面对这一情况，我意识到必须对代码进行优化精简。由于题目对代码长度有限制，而其他同学能够用 200 多行代码解决问题，这说明我的代码存在冗余。

恰逢老师讲解了集合与链表的相关知识，我发现许多原本自己编写的方法可以利用集合与链表的内置方法替代，从而大大减少了代码量。

经过一系列的修改和优化，我最终成功将代码长度控制在允许范围内，实现了代码的提交。

总结

通过本次任务，我深刻认识到在编程过程中，不仅要关注算法的正确性，还要注重代码的结构设计、细节处理以及代码的简洁性和可读性。同时，合理运用已学的知识和工具，能够有效提高代码质量和开发效率。在未来的学习和实践中，我将更加注重这些方面，不断提升自己的编程能力。

• 代码规模方面：该文件总行数为483行，其中可执行语句有317条，分支语句占比20.5%，方法调用语句为200条。整体来看，代码具备一定的规模，分支语句占比表明代码逻辑有一定复杂度，而较多的方法调用语句反映出方法间交互频繁，在代码结构和执行逻辑上均有优化的空间。
• 代码质量层面：注释行仅占1.7% ，极低的注释占比使得代码可读性极差，无论是对于初次接触该代码的开发者，还是原作者后续进行维护，都将面临极大的理解困难。文件中共有7个类和接口，平均每个类包含5.00个方法，每个方法平均有7.74条语句。虽然类和接口数量相对较多，但平均每个类的方法数量以及每个方法的语句数量表明，仍需进一步审视类的职责划分是否合理，目前的情况暗示着可能存在部分类功能不够单一，存在职责较为集中的问题，一定程度上违背了单一职责原则（SRP）。
• 代码复杂度方面：最复杂的方法 Controller.checkInput() 圈复杂度达到16，从第156行开始，且最深代码块在第178行，最大块深度为7 。较高的圈复杂度和较深的嵌套深度说明该方法逻辑复杂，理解和维护难度较大，可能需要耗费较多的时间和精力去理清其中的逻辑关系，这也迫切需要对复杂方法进行优化重构，以降低复杂度，提升代码质量。

题目集7单部电梯调度问题分析

题目如下：

7-3 NCHU_单部电梯调度程序（类设计-迭代）
分数 50
较难
作者 段喜龙
单位 南昌航空大学
对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段相同，但有如下变动情况：

乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
注意：本次作业类设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次及第二次电梯程序提交到本次题目中测试）。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<请求源楼层，请求目的楼层>，其中，请求源楼层表示乘客发起请求所在的楼层，请求目的楼层表示乘客想要到达的楼层。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：

1
20
<5,4>
<5>
<7>
end
输出样例1:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
输入样例2:
在这里给出一组输入。例如：

1
20
<5,9>
<8>
<9,3>
<4>
<2>
end
输出样例2:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Open Door # Floor 8
Close Door
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
Current Floor: 3 Direction: DOWN
Current Floor: 2 Direction: DOWN
Open Door # Floor 2
Close Door
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB）

SourceMonitor报表分析

类图分析

分析与心得

这次的题目和上次的类图大体一致，只是新增了 Passenger 类，并且把外部请求的方向参数换成了目标楼层数。实际上，这道题难度不算大。

我在上次代码的基础上进行了修改。在 inputCheck 方法里，对于外部请求的检查，我把原先判断第二位是否为 UP 或者 DOWN，改成了判断是否为一个介于最大楼层数和最低楼层数之间的数字。在处理请求的方法中，我将逗号右边的内容解析为目标楼层数，通过比较大小得出外部请求的方向，这样就能沿用之前的算法继续运行了。当执行外部请求后，我会把该请求的目标楼层数添加到内部请求队列的末尾。

不过，这次又遇到了代码超过最大长度限制的问题，这着实让我头疼不已。于是，对代码进行 “瘦身” 成了首要任务。借鉴上一次的解决办法，我提取了一些重复代码，例如将删除执行过的请求这一操作封装成一个方法。同时，我把左花括号的位置从次行调整到了末尾，经过这些优化，最终成功解决了代码过长的问题。

代码规模方面

我认为，从第二张图呈现的数据来看，这个 E3.java 文件的总行数达到 483 行，语句数也有 317 条，规模着实不算小。再瞧瞧第一张图里的类图，像 Passenger、RequestQueue、Elevator、Controller 等多个类相互关联、协同运作，这无疑让代码结构变得更加复杂。

这么多的行数和语句，明显表明代码在体量上是有一定规模的。而 20.5% 的分支语句占比，说明代码在逻辑判断方面的复杂程度不容小觑。频繁出现的 200 条方法调用语句，更是反映出类与类之间、方法与方法之间的交互十分频繁。在我看来，后续进行优化和维护时，必须得认真梳理代码结构了，不然可读性和可维护性真的很难保证。

代码质量层面

就我个人的看法，注释行仅仅占 1.7% ，这实在是太少了。再结合类图中类与类之间错综复杂的关联关系，比如 RequestQueue 和 Passenger 通过 QQ 关联，Controller 又与 RequestQueue、Elevator 相关联，这么低的注释占比，想要理解代码简直太难了。

文件里一共有 7 个类和接口，平均每个类有 5.00 个方法，每个方法平均还有 7.74 条语句。从类图设计的本意来讲，多个类应该是各自负责特定的功能。但现在的情况让我觉得，类的职责划分可能并不清晰。说不定有些类承担了过多的功能，导致不同类之间的界限变得模糊，这在很大程度上违背了面向对象设计里的单一职责原则，对代码的可维护性和扩展性都产生了不好的影响。

代码复杂度方面

在我眼中，最复杂的方法 Controller.checkInput() 圈复杂度竟然高达 16，从第 156 行开始，而且最深代码块在第 178 行，最大块深度为 7 。

从类图中类与方法的关系来分析，这个方法在 Controller 类里占据着核心位置，主要负责处理输入相关的逻辑。然而，这么高的圈复杂度和较深的嵌套深度，充分说明它内部的逻辑极其复杂，很可能存在多种条件判断和循环嵌套。这不仅会让我们理解这个方法的逻辑时困难重重，而且在后续进行修改和调试的时候，特别容易引发一系列连锁反应，进而影响整个系统的稳定性。依我看，迫切需要对这个方法进行重构优化，只有这样才能降低复杂度，提升代码的整体质量。

三、踩坑心理

1、题目集 5：初涉难题的迷茫与挫败

在处理输入时，因正则表达式知识匮乏，面对 inputCheck 方法的编写手足无措，反复尝试却始终无法正确匹配输入格式，那种无从下手的无力感令人焦虑。同时，对题目细节的疏忽，如忽略 end 结束条件的大小写问题，导致程序反复出错却找不到原因，内心满是挫败与自我怀疑。在算法设计环节，先入为主地将现实逻辑代入题目，多次误解 “方向优先” 原则，调试无果后陷入深深的自我否定，甚至产生放弃的念头。最终在深夜调试成功时，之前的焦虑与挫败瞬间转化为巨大的成就感，也深刻认识到细节与严谨的重要性。

2、题目集 6：细节疏忽与逻辑混乱的双重打击

实现去重功能时，因粗心大意误解题目要求，按照自己错误的理解编写代码，在一个测试点上反复栽跟头，内心充满懊恼与不甘。类拆分后程序出现逻辑错误，执行结果与预期大相径庭，使用 debug 排查问题的过程漫长而煎熬，每一次断点调试都像是在黑暗中摸索，担心找不到问题根源导致前功尽弃。面对代码量超限制无法提交的情况，从最初的慌乱无措，到冷静下来思考优化方向，过程中不断质疑自己的代码能力，也对类设计和代码复用有了更深的思考。

3、题目集 7：旧问题重现与优化的焦灼

尽管题目本身难度看似不大，但再次遭遇代码长度超限制的问题，瞬间陷入焦虑与无奈，感觉之前的努力仿佛白费，不知从何处下手优化。在提取重复代码、调整代码格式的过程中，每一次修改都小心翼翼，担心引入新的错误，内心充满对代码质量和提交结果的担忧。不断尝试不同的优化策略，却始终不确定是否能成功，在等待代码提交结果时，内心的紧张与期待交织，最终成功解决问题后，对代码优化和编程细节有了更深刻的敬畏之心。

四、改进建议

1、输入处理方面

正则表达式运用：

深入学习正则表达式，构建更精确、通用的匹配规则，减少对复杂 if - else 语句的依赖。例如，将输入验证逻辑封装成独立的工具类，提高代码复用性。

结束条件判断：

在处理输入结束条件时，统一使用 equalsIgnoreCase 方法，避免因大小写问题导致的错误。

2、算法设计方面

明确调度规则：

严格按照题目要求的 “方向优先” 原则设计算法，避免将现实逻辑与题目规则混淆。可以编写测试用例来验证算法的正确性。

借鉴优秀思路：

遇到难题时，积极参考他人的优秀代码和思路，但要深入理解后再应用到自己的代码中。

3、代码质量方面

遵循单一职责原则：

对类和方法进行合理拆分，确保每个类和方法只负责单一功能。例如，将输入处理、请求调度、状态管理等功能分别封装到不同的类中。

增加代码注释：

为关键代码和复杂逻辑添加详细的注释，提高代码的可读性和可维护性。注释比例应不低于 20%。

优化代码复杂度：

对圈复杂度高的方法进行重构，减少嵌套层级，使用更简洁的逻辑实现相同的功能。

五、总结

在完成题目集 5-7 的单部电梯调度程序系列任务过程中，我经历了从编程新手向具备基础工程思维的转变，不仅深化了对 Java 语言的理解，更在实践中构建起面向对象编程的完整认知体系。

一、知识体系的构建与深化

从题目集 5 的单一Elevator类实现，到题目集 6 基于单一职责原则的类拆分，再到题目集 7 的迭代式需求响应，我系统掌握了类的设计、属性封装、方法调用等核心技能。在处理电梯调度算法时，通过对 "方向优先" 规则的反复打磨，熟练运用队列数据结构管理请求序列，理解了枚举类型在状态管理中的高效应用。特别是在集合框架的实践中，学会利用ArrayList、LinkedList等工具替代自定义数据结构，显著提升了代码效率与简洁性。

二、实践能力的全面提升

这三次作业如同三次小型软件开发项目，让我在需求分析、编码实现、调试优化的完整流程中得到锻炼。在输入校验环节，从最初对正则表达式的陌生到能够独立设计校验规则；在算法设计阶段，通过不断试错建立起严谨的逻辑思维；在调试过程中，熟练掌握了 IDEA 的断点调试技巧，学会通过变量追踪定位问题根源。这些实践经验的积累，使我面对复杂编程任务时更具系统性解决能力。

三、问题解决与思维转变

编程过程中遭遇的诸多挑战，成为推动我成长的关键动力。题目集 5 中对结束条件的疏忽、题目集 6 中类拆分后的逻辑错误，以及多次代码规模超限问题，都迫使我从错误中反思总结。特别是在处理复杂逻辑时，逐渐学会将大问题拆解为可管理的小模块，通过分而治之的策略降低问题复杂度。这种思维转变不仅适用于编程，更为未来解决实际工程问题奠定了基础。

四、现存不足与改进方向

尽管取得了一定进步，但仍存在明显短板。在代码质量方面，注释缺失、类职责不清、方法复杂度高等问题依然突出；在技术深度上，对设计模式的应用仅停留在理论认知，缺乏实际项目经验；在工程规范上，单元测试、代码评审等环节尚未形成习惯。未来计划通过系统学习设计模式、参与开源项目、定期进行代码审查等方式，针对性提升薄弱环节