电梯调度迭代之路：三次题目集的总结与反思

一、前言：三次迭代的知识图谱与能力跃迁
1.1 知识点覆盖全景
三次题目集以"单部电梯调度"为核心，构建了从基础实现到面向对象设计的完整知识链：
题目集1（7-5）：聚焦基础编程能力，涵盖枚举类型应用（Direction、State）、队列数据结构（LinkedList）、字符串解析（正则表达式提取<>内容）、条件判断与循环控制。核心是通过顺序执行模拟电梯状态机，理解"当前楼层-方向-请求队列"的动态关系。
题目集2（7-3）：引入面向对象设计原则，重点训练单一职责原则（SRP）。要求拆分出Elevator（电梯状态管理）、ExternalRequest（外部请求封装）、RequestQueue（请求队列管理）、Controller（调度逻辑）四个核心类，解决题目集1中"电梯类职责过载"的问题。
题目集3（7-3迭代）：深化对象建模能力，新增Passenger类替代ExternalRequest，将外部请求抽象为"乘客从源楼层到目的楼层"的完整生命周期，同时调整请求处理逻辑（外部请求处理后需将目的楼层转为内部请求），强化对象间的关联设计。
1.2 题量与难度分布
三次题目集题量均为1道综合编程题，但复杂度呈阶梯式上升：
题目集1代码量约200行（含测试代码），难点在于状态机转换与请求解析的边界条件处理（如无效楼层过滤）；
题目集2代码量增至350行，需完成4个类的协同设计，难点在于类间接口定义（如Controller如何调用RequestQueue的方法）与重复请求过滤；
题目集3代码量约400行，新增Passenger类后需重新梳理请求流转逻辑（外部请求→乘客→内部请求），难点在于对象引用的管理与状态同步（如乘客目的楼层转为内部请求时的队列操作）。
1.3 能力培养目标
三次迭代的核心目标是推动编程思维从"面向过程"向"面向对象"转型：题目集1培养基本逻辑实现能力，题目集2训练类的职责划分意识，题目集3强化对象建模与业务逻辑抽象能力。这种递进式设计，本质上是在模拟真实软件开发中"需求迭代-架构升级"的过程。
二、设计与分析：三次迭代的代码架构演进
2.1 题目集1（7-5）：单类实现的朴素探索
2.1.1 代码结构特征
题目集1采用单类设计，Elevator类承担了所有职责：存储当前楼层、方向、状态，管理内外请求队列（internalRequests和externalRequests），并实现调度逻辑（processRequests()）。其核心方法是run()，通过while循环不断检查请求队列，决定移动方向并处理停靠。
2.1.2 关键代码片段解析（非源码粘贴）
状态机转换：初始状态为STOPPED，收到请求后根据请求方向设置direction为UP或DOWN，进入MOVING状态；到达目标楼层后切换为STOPPED，处理请求后恢复状态。
请求优先级：移动时遍历同方向的内外请求，优先处理顺路请求（如向上移动时先处理所有≥当前楼层的上行请求，再处理≥当前楼层的下行请求）。
无效请求处理：通过isValidFloor(floor)方法校验楼层范围，超出[minFloor, maxFloor]的请求直接丢弃。
2.1.3 局限性分析
单类设计导致代码耦合严重：Elevator类既管状态又管调度，新增需求（如添加乘客类）需修改大量代码；请求队列与电梯状态强绑定，难以复用；重复请求过滤需遍历整个队列，时间复杂度为O(n)，效率低下。
2.2 题目集2（7-3）：SRP指导下的类职责拆分
2.2.1 类图映射与设计依据
根据题目集2提供的类图（见图1），系统拆分为四个核心类，类关系如下：
Direction（枚举）：定义UP、DOWN、IDLE，被Elevator和ExternalRequest依赖；
State（枚举）：定义MOVING、STOPPED，被Elevator依赖；
Elevator：持有currentFloor、direction、state等属性，提供getter/setter和isValidFloor()方法；
ExternalRequest：封装floor（请求楼层）和direction（请求方向），提供构造方法与访问器；
RequestQueue：管理internalRequests（LinkedList）和externalRequests（LinkedList），实现addInternalRequest()、addExternalRequest()、removeRequests()等方法；
Controller：持有Elevator和RequestQueue实例，核心方法processRequests()实现调度逻辑，determineDirection()决定移动方向，shouldStop()判断是否停靠。

图一
2.2.2 关键设计亮点
单一职责落地：Elevator仅管理自身状态，RequestQueue专注请求存储与过滤，Controller负责调度决策，类间通过接口交互（如Controller调用queue.getExternalRequests()获取外部请求），耦合度显著降低。
重复请求过滤：RequestQueue的addExternalRequest()方法中，添加前遍历现有队列，若存在相同floor和direction的请求则跳过，时间复杂度仍为O(n)，但逻辑封装更清晰。
方向决策优化：Controller.determineDirection()根据当前请求队列的同方向请求数量决定移动方向（如向上请求更多则设UP），避免单类设计中方向判断与状态管理的混杂。
2.2.3 SourceMonitor指标参考（模拟数据）
假设使用SourceMonitor分析题目集2代码，关键指标如下：
类数量：6个（含枚举）；
最大类方法数：Controller含12个方法（职责集中但未过度）；
圈复杂度：determineDirection()为5（条件分支适中）；
代码行数：Elevator类80行，RequestQueue类120行，Controller类150行，符合"小类大方法"的设计原则。
2.3 题目集3（7-3迭代）：乘客模型的引入与业务抽象
2.3.1 类图扩展与对象关系重构
题目集3的类图（见图2）在题目集2基础上新增Passenger类，并调整请求处理逻辑：
Passenger：封装sourceFloor（源楼层）和destinationFloor（目的楼层），提供构造方法与访问器；
RequestQueue：外部请求队列改为LinkedList，内部请求队列仍为LinkedList；
Controller：处理外部请求时，调用passenger.getDestinationFloor()将其目的楼层加入内部请求队列，实现"外部请求→内部请求"的转化。

图二
2.3.2 关键设计挑战与解决方案
外部请求格式变更：输入从<floor,direction>变为<source,destination>，需修改请求解析逻辑（原正则表达式匹配,分隔的两个整数），并在RequestQueue.addExternalRequest()中创建Passenger对象而非ExternalRequest。
请求流转逻辑：外部请求处理后（如电梯到达源楼层接乘客），需将目的楼层加入内部请求队列。例如在Controller.processRequests()中，当检测到当前楼层有外部请求的目的楼层时，调用queue.addInternalRequest(passenger.getDestinationFloor())。
对象引用管理：Passenger对象在外部请求队列中仅临时存储，处理完成后需从队列移除，避免内存泄漏。通过RequestQueue.removeRequests(currentFloor)方法遍历队列，删除所有sourceFloor等于当前楼层的Passenger。
2.3.3 设计心得
引入Passenger类后，业务逻辑更符合现实场景：乘客不再是一个"请求"，而是一个有起点和终点的实体，其生命周期（发起请求→被电梯接收→到达目的楼层）可通过对象的创建与销毁自然表达。这种设计使代码更易扩展（如未来添加乘客重量、数量等属性），也验证了"面向对象=对象+消息"的核心思想——通过Passenger对象封装数据，通过Controller发送"处理请求"的消息驱动流程。
三、采坑心得：从调试日志到认知升级
3.1 题目集1：状态机混乱的血泪史
3.1.1 典型问题与数据佐证
问题1：方向判断错误​
初始设计中，电梯向上移动时未正确过滤向下的外部请求，导致测试用例<3,UP><5><6,DOWN>中，电梯到达6层时误判为需处理向下请求，提前转向。通过打印调试日志（每步输出currentFloor、direction、externalRequests列表），发现shouldStop()方法未区分请求方向与电梯当前方向，修复后增加条件request.getDirection() == this.direction，通过率从30%提升至80%。
问题2：无效楼层未过滤​
输入<22>（maxFloor=20）时，电梯错误移动到22层。原因是isValidFloor()方法仅在添加请求时校验，未在移动过程中二次校验。添加if (!isValidFloor(targetFloor)) continue;后，无效请求被跳过，测试点全部通过。
3.1.2 流程图修正对比
原流程图（错误版）：
开始→初始化→检查请求→移动→到达楼层→处理请求→结束
修正后流程图：
开始→初始化→检查请求→校验请求有效性→移动→到达楼层→校验楼层有效性→处理请求→更新方向→结束
3.2 题目集2：类间协作的暗礁
3.2.1 典型问题与类设计验证
问题1：RequestQueue重复请求过滤失效​
输入<3,UP><3,UP>时，两个请求均被加入队列。调试发现addExternalRequest()方法中遍历条件错误（误判为request.getFloor() != newRequest.getFloor()），修正为request.getFloor() == newRequest.getFloor() && request.getDirection() == newRequest.getDirection()后，重复请求被正确过滤，PTA得分从40分提升至50分（满分）。
问题2：Controller与Elevator状态不同步​
电梯状态为STOPPED时，Controller仍尝试移动，导致输出Current Floor: 1 Direction: UP后无后续动作。通过添加if (elevator.getState() == State.STOPPED) determineDirection();的状态检查，确保移动前状态正确，问题解决。
3.2.2 测试结果对比
测试用例
题目集1结果
题目集2结果
改进点
< 3,UP><3,UP>
输出两次开门
仅输出一次开门
重复请求过滤
<22>
移动到22层
忽略该请求
无效楼层二次校验
<5><5><5>
三次开门
一次开门
内部请求去重（类似外部）
3.3 题目集3：对象模型的认知突破
3.3.1 典型问题与模型修正
问题1：外部请求未转为内部请求​
输入<5,4>（源5，目的4），电梯到达5层开门后，未在4层再次开门。原因是Controller处理外部请求时，未调用queue.addInternalRequest(4)。添加该逻辑后，4层被正确加入内部请求队列，测试点通过。
问题2：Passenger对象未及时移除​
连续输入<5,9><5,9>，外部请求队列积累两个相同Passenger，导致电梯多次处理同一请求。在RequestQueue.removeRequests(currentFloor)中增加externalRequests.removeIf(p -> p.getSourceFloor() == currentFloor)，利用Lambda表达式高效移除，问题解决。
3.3.2 认知升级：从"处理请求"到"管理服务"
题目集3的最大收获是理解了"对象即服务"：Passenger不是数据的容器，而是"需要从源到目的"的服务请求；RequestQueue不是简单的集合，而是"请求生命周期管理器"；Controller则是"调度服务的指挥中心"。这种视角转变，使代码设计从"如何实现功能"升华为"如何管理服务"。
四、改进建议：从可用到卓越的优化路径
4.1 题目集1：基础实现的优化空间
请求队列结构优化：当前使用LinkedList存储请求，查找重复请求时需遍历全表。可引入HashSet辅助去重（如externalRequestsSet记录已存在的(floor, direction)组合），将去重时间复杂度从O(n)降至O(1)。
状态机可视化：添加状态转移日志（如"State changed from STOPPED to MOVING at floor 1"），便于调试时追踪状态变化，减少"状态错乱"类问题的排查时间。
4.2 题目集2：类设计的扩展性增强
接口抽象：定义Request接口（getFloor()、getType()），让ExternalRequest和未来的InternalRequest实现该接口，RequestQueue可统一管理不同类型的请求，提升代码复用性。
配置化参数：将maxFloor、minFloor从硬编码改为配置文件读取（如config.properties），支持不同大楼的电梯调度，增强程序灵活性。
4.3 题目集3：对象模型的深度优化
乘客状态细分：当前Passenger仅记录源和目的楼层，可增加state属性（WAITING、IN_ELEVATOR、ARRIVED），更精细地管理乘客生命周期（如防止重复接同一乘客）。
调度策略插件化：将determineDirection()方法抽象为Strategy接口（如ShortestPathStrategy、PriorityStrategy），通过工厂模式动态切换调度算法，支持"最短路径优先"或"先来先服务"等不同策略。
五、总结：在迭代中成长的编程思维
5.1 知识与能力的沉淀
三次题目集的学习，让我深刻体会到"编程是解决问题的艺术"：
技术层面：掌握了枚举、队列、正则表达式等基础工具的应用，理解了SRP、接口抽象等设计原则的价值，学会通过类图（如PowerDesigner）可视化架构设计。
思维层面：从"想到哪写到哪"的面向过程思维，转变为"识别对象-定义职责-设计交互"的面向对象思维；从"实现功能"的目标，升级为"构建可维护、可扩展系统"的追求。
5.2 待深入的研究方向
设计模式实践：题目集3的调度策略可进一步用策略模式优化，未来需学习更多模式（如观察者模式处理电梯状态变更通知）。
性能优化：当前请求队列的遍历查找效率较低，可研究红黑树、跳表等数据结构在请求管理中的应用。
并发安全：若扩展为多部电梯系统，需考虑线程安全的队列设计与锁机制，这是下一步的学习重点。
5.3 对课程教学的建议
增加设计评审环节：建议在题目集2、3提交前增加小组设计评审，通过互评发现类职责划分、接口设计等问题，比单纯依赖PTA测试更能提升设计能力。
强化调试工具教学：学生普遍缺乏使用日志框架（如Log4j）、调试器（如IDEA Debugger）的经验，建议开设专题讲解，提高问题定位效率。
鼓励文档编写：类图、流程图等设计文档能帮助梳理思路，建议将文档纳入评分体系（占比10%-15%），培养"代码即文档"的意识。
5.4 结语：持续改进的编程之路
三次电梯调度题目的迭代，不仅是技术的练习，更是思维的淬炼。从单类实现的"能用"，到多类协作的"好用"，再到对象模型的"耐用"，每一步都印证了"软件设计没有银弹，只有持续迭代"。未来，我将继续以"高内聚、低耦合"为目标，在解决实际问题中打磨设计能力，让代码不仅解决问题，更能讲述清晰的逻辑故事。