题目集 1-3电梯调度程序实践与反思
一、前言
过去这些天里，我们开始了为期三周的电梯调度大作业学习，这三次题目集围绕电梯调度系统展开渐进式设计，体现了从基础到复杂、从单一功能到系统架构的完整学习路径。第一次题目集聚焦单部电梯的基础调度功能，重点考察面向对象的基本概念、字符串处理、集合框架使用和基础算法设计，题量适中但涵盖了编程的核心知识点。第二次题目集在原有基础上引入迭代开发概念，新增了类图设计、请求去重、异常处理等要求，难度明显提升，需要学生具备一定的系统设计能力。第三次题目集进一步深化架构设计，引入乘客类概念并改变请求格式，强调类间协作和数据流设计，对学生的抽象思维和系统分析能力提出了更高要求。
总体来看，这三次题目集形成了一个完整的渐进式学习体系：第一次夯实基础编程能力，第二次培养架构设计思维，第三次训练系统分析能力。题量设计合理，每次作业都在前次基础上增加新的技术要素，既保证了学习的连续性，又提供了足够的挑战性。知识点覆盖全面，从基础的语法、数据结构到进阶的设计模式、架构原则都有涉及，很好地体现了理论知识与实践能力的结合。这种循序渐进的任务设计方式，让我们在完成具体编码任务的同时，也能系统地提升软件工程思维能力。
二、设计与分析
1.题目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
代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB
报表分析
类图分析
分析与心得
1.类
1.ExternalRequests类：专门负责封装外部电梯请求信息，包含楼层和方向两个关键属性。通过提供标准化的获取方法，实现了对外部请求数据的统一管理，确保数据访问的一致性
2.Elevator类：电梯系统的控制中枢，全面管理电梯的运行状态，包括楼层范围控制、当前位置跟踪、运行方向决策等关键功能。同时协调处理内部请求队列和外部请求队列的调度逻辑
3.Main类：承担程序入口和流程协调者的角色，负责用户输入的解析与验证、请求类型识别、电梯实例的初始化以及整个处理流程的调度控制
2. 数据结构设计
采用ArrayList动态数组结构存储内外请求，充分考虑了电梯使用场景中请求数量的不确定性和动态变化特性。ArrayList的自动扩容机制为请求队列的灵活管理提供了便利
3. 交互设计
1.输入处理：建立标准化的输入协议，通过格式校验确保数据质量。设置明确的终止标识"End"来触发处理流程，形成清晰的请求收集与执行的阶段划分
2.处理流程：请求驱动的处理模式，电梯根据当前状态和待处理请求动态调整运行策略，实现调度决策
4.方法复杂度
Elevator.determineDirection()方法呈现出较高的圈复杂度，这反映出方向决策逻辑中存在过多的条件分支和状态组合。Main.main()方法同样承担了过多的职责，违反了单一职责原则。虽然能够满足基本功能需求，但在处理复杂场景时可能表现出效率瓶颈，特别是在高峰期的请求密集场景下
5.算法设计
算法设计是本题最具挑战性的部分，我多次误解了题目的意思。比如在看到测试样例中，电梯在 5 楼时同时收到内部请求的 7 楼和外部请求的 6 楼，按照自己的理解，认为应该先处理距离较近的 6 楼请求，但实际结果却是先到 7 楼。这是因为我一直将现实生活中电梯的调度逻辑套用到程序中，忽略了题目中方向优先的原则。经过不断地调试和修改，终于成功通过了所有测试点。
6.代码质量分析
通过 SourceMonitor 生成的代码分析报告，可以清晰地看出我提交的代码虽然通过了测试点，但在质量上存在严重问题：
1.Lift.chocserw()方法（圈复杂度10）：12条语句中包含深层嵌套逻辑，最大嵌套深度达到8层，14次方法调用表明该方法承担了过多职责，达到危险级别的复杂度，远超安全阈值。
2.Lift.outsideHait()方法【圈复杂度10】：同样达到复杂度上限，维护噩梦。17次方法调用！耦合度爆炸，外部请求处理逻辑与内部状态管理完全混杂。
3.Main.main()方法【28条语句】：入口方法承担了输入解析、验证、业务协调所有职，8层嵌套深度，控制流如同迷宫
4.平均每个方法5.87条语句掩盖了真相：少数方法极其复杂，多数方法过于简单，块深度分析显示深度2的语句占34.8%，说明整个代码库都沉浸在条件嵌套中，方法间调用关系混乱，形成复杂的依赖网。
此次经历让我深刻认识到，在编程过程中，不仅要实现功能，更要注重代码的规范性、可读性和可扩展性。未来，我将加强对设计原则的学习和应用，合理拆分类的职责，不断提升代码的质量。
2.7-3 NCHU_单部电梯调度程序（类设计）
分数 50
作者 段喜龙
单位 南昌航空大学
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。
电梯迭代1类图.png
电梯运行规则与前阶段单类设计相同，但要处理如下情况：
乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<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
点击查看代码
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
点击查看代码
1
20
<3,UP>
<3,UP>
<5>
<5>
<5>
<6,DOWN>
<7>
<7>
<3>
<22,DOWN>
<5,DOWN>
<30>
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
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door
设计与总结
在开始第二个电梯调度程序开发时，我首先面临的是需求理解的挑战。虽然题目要求很明确——要解决电梯类职责过多的问题，但实际操作时才发现自己对"单一职责原则"的理解还停留在理论层面。例如，在最初的设计中，我仍然习惯性地把请求验证逻辑放在了电梯类中，这直接违背了单一职责原则。后来经过反复思考才意识到，输入验证应该由专门的请求处理类负责。
1.类图设计的挣扎：最初认为"队列类就是简单存储请求的容器"，忽略了队列类应该具备去重、过滤等智能处理能力对类之间的协作关系考虑不周全。我陷入了"为了设计而设计"的误区，创建了过多细粒度的类，导致类间关系复杂化。后来通过查阅资料才明白，好的设计应该是在保证单一职责的前提下，尽量减少类间的耦合度。
2.重复请求过滤：在实现去重逻辑时，我最初只考虑了简单的字符串比较，后来测试时发现这种方法无法正确处理<3>和<3,UP>这种看似相同实则不同的请求。这让我意识到需要建立更完善的请求标识机制
3.电梯调度算法的重构痛苦：在第一个版本中，所有调度逻辑都集中在电梯类的一个大方法中。现在要拆分成多个类协作，我遇到了数据同步和状态管理的难题：控制类如何获取电梯的当前状态？队列类如何通知控制类有新的有效请求？各个类之间应该如何传递信息？在这个过程中，我深刻体会到了"解耦"的代价——虽然架构更清晰了，但复杂度从代码层面转移到了设计层面。
4.边界条件处理疏忽：最初我只考虑了楼层数是否在[min, max]范围内，但忽略了几个重要情况：当前楼层就是请求楼层时如何处理多个无效请求连续出现时的程序稳定性，"end"输入的大小写兼容性问题。在测试样例2时，程序因为连续无效请求而出现了异常终止，这暴露了我在异常处理方面的经验不足。修正后的流程：输入 → 验证 → 去重 → 入队 → 调度决策 → 电梯运动 → 请求完成 → 出队。这个看似简单的流程，在实际编码中却需要精确的状态管理和消息传递。
5.反思与成长
1.通过这次迭代开发，我真正理解了"单一职责原则"不仅仅是把大类拆成小类，更重要的是：要能准确判断某个功能应该属于哪个类的职责，要设计出清晰、高效的类间协作机制，确保修改一个类的实现不会影响其他类。
2.在第一个版本中，我的目标是"只要能通过测试点就行"。但在第二个版本中，我开始思考：代码是否易于扩展？是否方便后续维护？别人是否能快速理解我的设计？这种思维转变让我开始重视代码的可读性、注释的完整性以及设计的合理性。
3.从最初面对需求时的茫然，到能够基于原则进行类设计，这是一个质的飞跃。虽然最终实现可能还不够完美，但设计思路已经朝着正确的方向发展。
6.总结
这次电梯调度程序的迭代开发，对我来说不仅仅是一次编程作业，更是一次工程思维的洗礼。从第一个版本的"勉强能用"到第二个版本的"追求好设计"，我经历了痛苦的思维转变和技术突破。
虽然最终没有完全通过所有测试点，但在这个过程中获得的设计思维、调试技巧和问题解决能力，远比一个完美的分数更加珍贵。我深刻认识到，软件开发的本质不是编写代码，而是通过代码解决问题，而良好的设计是高效解决问题的关键。
这次经历让我真正理解了"迭代开发"的意义——每一次迭代不仅是功能的增强，更是开发者自身能力的提升。在未来的学习中，我将继续保持这种反思和改进的态度，在技术上持续精进，在思维上不断突破。
3.7-3 NCHU_单部电梯调度程序（类设计-迭代）
分数 50
作者 段喜龙
单位 南昌航空大学
对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。
类图.png
电梯运行规则与前阶段相同，但有如下变动情况：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
注意：本次作业类设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次及第二次电梯程序提交到本次题目中测试）。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<请求源楼层，请求目的楼层>，其中，请求源楼层表示乘客发起请求所在的楼层，请求目的楼层表示乘客想要到达的楼层。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：
运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：
点击查看代码
1
20
<5,4>
<5>
<7>
end
点击查看代码
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
点击查看代码
1
20
<5,9>
<8>
<9,3>
<4>
<2>
end
点击查看代码
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
很遗憾，第三次也没有通过测试点，报表在此也不贴了
类图分析
分析与总结
当我看到第三次迭代的需求时，内心是崩溃的。这次的改动不仅仅是功能调整，而是整个架构理念的根本性变革：外部请求从<楼层,方向>变为<源楼层,目的楼层>，新增Passenger类取代原有的简单请求类，请求处理逻辑需要完全重新设计。
最初的反应是抗拒："为什么又要重写？前一个版本好不容易才理解清楚！"这种情绪让我在开始阶段就陷入了消极状态，浪费了宝贵的时间。
1.类图理解的深度困惑：面对提供的类图，我经历了从"看似明白"到"实际迷茫"的过程。
1.1 Passenger类同时包含sourceFloor和destinationFloor，但何时赋值不明确Controller类的determinBifrection方法（明显是determineDirection的拼写错误）增加了理解难度，各个类之间的协作关系比前两次更加复杂。
我花了整整一天时间研究类图，试图理解每个方法的职责，但越看越困惑。这种架构理解的无力感让我开始怀疑自己的面向对象基础。
1.2 Passenger类设计的认知偏差：
1.2.1最初的设计误区：我以为Passenger类只是简单封装两个楼层数字，但实际开发中发现远远不够.这个认知偏差导致我在后续开发中不断回头修改Passenger类，形成了设计→编码→发现问题→重新设计的恶性循环。
1.2.2外部请求处理的逻辑迷宫：外部请求处理后的目的楼层加入内部队列，我最初的理解是简单的队列操作，但实际实现时发现需要考虑：
何时加入？电梯到达源楼层时还是离开时？
如何避免重复添加？
方向如何确定？
这个问题让我卡了整整两天，尝试了多种方案：
方案一：在Controller的removeRequests方法中处理
方案二：在RequestQueue中添加时自动处理
方案三：在Elevator到达楼层时处理
每种方案都有缺陷，最终选择在Controller中处理，但逻辑仍然不够清晰。
1.3方向决策算法的重构痛苦
第二次迭代中的方向决策已经很难，这次因为请求结构的改变，算法需要完全重写：
新旧算法对比的困惑：
旧算法：基于当前方向+请求方向决策
新算法：基于当前方向+源楼层+目的楼层决策
我试图沿用之前的SCAN算法思想，但发现无法直接套用。在迷茫中，我尝试了：
基于最近距离的贪心算法
基于请求时间的FIFO算法
混合策略
但都没有达到理想效果，电梯运行路径总是出现不合理的折返。
2.调试过程中的绝望与突破
2.1无限循环的噩梦：最令人绝望的是程序陷入了无限循环，问题根源： 请求没有正确移除，导致电梯在两个楼层间来回震荡。通过添加详细的调试日志，才发现问题出在：
外部请求处理后，新的内部请求没有正确标记
电梯状态更新时机错误
请求出队逻辑有漏洞
2.2样例2通不过的技术深渊
输入样例2的复杂场景让我的程序完全失控，我的程序输出与预期相差甚远，主要表现在：
电梯运行路径不合理，存在大量空跑
请求服务顺序混乱
方向改变逻辑不符合预期
经过逐行调试，发现了多个隐蔽的bug：
同楼层多个请求处理错误
方向决策时没有考虑所有待处理请求
楼层有效性验证有遗漏
3.架构设计层面的深度反思
3.1单一职责原则的重新理解，通过这次痛苦的迭代过程，我对SRP有了更深刻的认识。
3.2接口设计的重要性，这次迭代让我深刻认识到良好的接口设计是成功的一半，我的设计缺陷是类之间依赖过于紧密，方法参数设计不合理，异常处理考虑不周全，理想的设计应该，定义清晰的接口契约，减少类间的直接依赖，提供灵活的扩展点。
4. 成长与转变
最初的心态：
"这个需求太复杂了"
"我肯定做不出来"
"能不能用之前的代码修修改改"
调整后的心态：
"这是一个学习机会"
"每次调试都是进步"
"理解比完成更重要"
这种心态转变让我从被动应付变为主动学习，虽然最终没有完全通过测试，但收获远超预期。
5.总结：
第三次电梯调度迭代开发，从结果上看是失败的——我没有完全通过测试点。但从过程来看，这是一次宝贵的学习经历。
我经历了从技术迷茫到逐渐清晰，从心理崩溃到重拾信心的完整心路历程。在这个过程中，我不仅学习了技术知识，更重要的是培养了面对困难的勇气和解决问题的能力。
这次经历让我明白：在软件工程的道路上，暂时的失败不可怕，可怕的是失去学习和进步的勇气。每一个bug、每一次调试、每一行代码，都是成长的阶梯。
虽然这次作业没有完美完成，但我获得的架构思维、调试经验和心理韧性，将在我未来的技术生涯中持续发挥价值。这，或许就是教育的真正意义所在。
三、采坑心得
1.题目集1：单部电梯调度的艰难起步
1.1 初次面对复杂需求的茫然：第一次接触电梯调度题目时，内心充满了忐忑。看着题目描述中各种规则和要求，感觉信息量巨大，不知从何入手。特别是看到输入格式要求、运行规则、输出规范等细节时，产生了强烈的畏难情绪。
真实困境：
对Java集合框架不熟悉，不知道选择ArrayList还是LinkedList
面对正则表达式要求感到无从下手
对面向对象设计缺乏实践经验
记得在开始编码前，我整整犹豫了一天，反复阅读题目要求，试图在脑海中构建整个程序框架，但总是感觉思路混乱。这种"想得多做得少"的状态持续了很久，直到截止日期临近才不得不开始动手。
1.2 调试过程中的挫败感：在实现基础功能时，遇到了许多意想不到的问题，我花费了大量时间在处理输入格式的细节上，往往为了一个空格或者大小写问题调试好几个小时。每当看到一个"Wrong Format"的输出，内心就充满沮丧。电梯的调度算法看似简单，但实际实现时却漏洞百出。我记得有一次，电梯在1楼接到去5楼的请求后，直接显示"到达5楼"，完全忽略了中间楼层。这种低级错误让我怀疑自己的逻辑思维能力。
2.题目集2：迭代开发的现实困境
2.1 架构重构的理论与实践脱节
第二次作业要求按照单一职责原则重构代码，这听起来很合理，但实际操作却困难重重：
设计困惑：
知道要分多个类，但不知道如何划分职责边界
理解了单一职责的概念，但实践中难以把握分寸
类之间如何协作成为新的难题
我尝试绘制类图，但很快就陷入了"过度设计"的陷阱。设计了太多细粒度的类，导致实现时代码分散，逻辑支离破碎。
2.2功能实现的挣扎
去重功能的困惑：
题目要求过滤连续相同请求，我理解了这个需求，但在实现时：
不知道应该在哪个环节进行去重
担心去重逻辑影响其他功能
对"连续"的定义理解有偏差
由于时间关系，最终只实现了一个简单的去重逻辑，无法处理复杂情况。
2.3时间不足的无奈
最终只能提交一个未完成的版本，很多功能只是空壳，无法正常运行。这种"心有余而力不足"的感觉让人十分挫败。
3.题目集3：深度迭代的无力感
3.1架构理解的局限
第三次作业将外部请求格式从方向改为具体的目标楼层，这一变更看似简单，实则对系统架构产生了深远影响。我在理解需求时出现了严重偏差，误以为只需要修改输入解析部分，却忽略了这对整个调度算法的颠覆性影响
3.2类职责划分混乱Elevator类问题：
仍然保留了部分调度逻辑
状态管理不够清晰
与其他类的边界模糊
Controller类困境：
承担了过多的协调职责
方法复杂度失控
成为新的"上帝类"
Passenger类设计缺陷：
对内部请求和外部请求的处理逻辑混杂
缺乏统一的状态管理机制
3.3核心难点
原有的方向决策算法基于请求方向，现在需要基于源楼层和目标楼层动态计算方向。我在实现时：试图沿用旧的决策框架，导致逻辑混乱，没有建立新的决策依据标准，处理边界情况时出现逻辑漏洞。
这次失败经历让我深刻认识到，软件开发的每个环节都至关重要，任何一个细节的疏忽都可能导致全盘皆输。在今后的学习中，我需要更加注重基础能力的培养和工程化思维的建立。
四、改进建议
于我在后两次电梯调度作业中未能完成实现，基于这三次尝试的经验教训，我总结出以下几点具体可行的改进建议：
在架构设计方面，应该采用更务实的设计方法。不要一开始就追求完美的类图设计，而是先确定核心的数据流：请求如何进入系统、如何在各个模块间传递、最终如何驱动电梯运行。基于数据流来划分类职责，确保每个类都有明确且单一的职责。比如，可以专门设立一个RequestProcessor类来处理所有请求相关的逻辑，避免让Elevator类承担过多职责。
在开发策略上，应该采用垂直分层的实现方式。先实现最基本的数据结构和核心算法，确保电梯能够完成最简单的上下行和停靠。然后逐步添加输入解析、请求过滤、复杂调度等功能。每完成一个层次就进行充分测试，避免一次性开发过多功能导致调试困难。
对于算法实现，建议先完成一个可工作的基础版本，再考虑优化。比如先实现简单的FIFO调度，确保程序能够正常运行，然后再尝试实现更复杂的SCAN或LOOK算法。这样即使最终无法完成高级算法，至少还有一个可用的基础版本。
五、总结
1.学习收获与不足
过本阶段三次电梯调度题目的实践，我在面向对象编程方面获得了宝贵的经验。第一次作业让我掌握了基础的类设计方法，理解了封装的重要性。虽然在后续两次迭代中未能完全实现功能，但在分析需求、设计类图的过程中，我对单一职责原则、类间协作关系有了更深入的理解。特别是在分析失败原因时，我认识到自己对数据流设计、状态管理等方面存在明显不足
2.需要加强的领域
首先是架构设计能力，特别是在复杂系统中如何合理划分类的职责边界；其次是算法实现能力，需要加强将理论算法转化为实际代码的能力；最后是调试技巧，需要建立更系统化的调试方法。
3.课程改进建议
在复杂作业中提供关键算法的伪代码参考，或者给出一些典型的设计模式应用示例。对于迭代式开发的作业，建议提供阶段性的检查点，让学生能够及时获得反馈，避免在错误的方向上走得太远。外，是否可以建立一个常见问题解答库，收集往届学生在同样作业中遇到的问题和解决方案。
最后，我想说的是，虽然我在后续作业中遇到了困难，但这种循序渐进的作业设计方式确实有助于我们建立系统的编程思维。希望老师能够继续保持这种注重实践的教学方式，相信通过不断积累经验，我们都能在编程能力上获得实质性的提升。
![P4555 [国家集训队] 最长双回文串 踢姐](http://pic.xiahunao.cn/P4555 [国家集训队] 最长双回文串 踢姐)
