一、前言
电梯调度系统是典型的实时请求处理与资源优化分配问题，核心目标是模拟现实中电梯的运行逻辑，在满足乘客多样化请求（内部选层、外部召梯）的前提下，遵循 “同方向优先、顺路处理” 的调度规则，同时处理无效请求、重复请求等异常场景，最终实现高效、符合直觉的电梯运行模拟。
随着三次作业的迭代，需求从 “单一类实现核心功能” 逐步演进为 “遵循单一职责原则的多类协同”，并最终引入 “乘客实体” 抽象，让模型更贴近真实场景。整个过程不仅是代码结构的优化，更是对 “请求本质”“模块解耦”“业务流程闭环” 的深度打磨。
知识点：涉及电梯模型核心逻辑，包括队列之间的联动（外部请求→内部请求）、对象属性的同步更新、类之间的职责划分、依赖关系设计（如Controller依赖Elevator和RequestQueue）、电梯的状态（STOPPED/MOVING）与动作（移动、开门、关门）的联动，确保动作仅在合法状态下执行（如仅停止时可开门）、贪心算法（同方向优先本质是贪心策略）……
题量与难度：
二、设计与分析
三次题目集的核心均为“对一部电梯的调度”，以下从类设计、调度逻辑及源码指标三个维度展开分析。
三、第一次题目集设计与分析
1.类结构设计（单一类）
//定义电梯的运行方向枚举，避免硬编码字符串，确保方向的规范性和可读性。
public enum Direction {
UP, DOWN, IDLE
}
//初始化电梯的基础配置、当前状态和请求队列，确保电梯启动时处于默认有效状态。
public Elevator(int minFloor, int maxFloor) {}
//匹配外部请求（<楼层,UP/DOWN>）和内部请求（<楼层>）
private void parseAndAddRequest(String line) {
private Queue
private Queue
private Queue
}
//查找当前楼层最近的请求楼层
private int findNearestRequest() {}
//电梯移动模拟，更新当前楼层并输出移动信息
private void moveOneFloor() {}
类图如下：
2.调度逻辑
我的电梯调度器遵循 “同向优先、即时换向、就近响应” 原则，核心目标是平衡 “运行效率” 和 “请求响应及时性”，避免无效楼层折返。调度逻辑的核心流程是：确定方向 → 移动 → 停靠处理请求，但有一些问题，如下：
（1）避免 “方向切换延迟”
错误逻辑：同向请求需运行到 “最远楼层” 才换向（如 UP 方向需到最高请求层才转 DOWN），导致近楼层请求延迟。
你的优化：通过 hasRequestInDirection() 实时检查当前方向是否有有效请求（当前楼层之上 / 之下），一旦无请求立即换向（如 UP 方向无更高请求，直接切 DOWN），无需等待最远楼层。
示例：输入<3,UP>、<2,UP>、<5>（初始楼层 1）
调度流程：1→2（处理 UP 请求）→3（处理 UP 请求）→5（处理内部请求）→ 无 UP 请求，切 DOWN（无需到更高楼层）→ 无 DOWN 请求，任务结束。
路径：1→2→3→5（共 3 层移动），避免了 “先到 5 再折返 2、3” 的无效路径。
（2）避免 “请求查找范围错误”
错误逻辑：遍历所有请求选择 “最远同向请求”，导致先输入的近楼层请求被忽略。
你的优化：
用 TreeSet 存储请求（天然升序排序），配合 findClosestRequestInDirection() 查找 “当前方向最近的请求”，优先响应距离近的请求。
示例：队列中存在 <2,UP>（近）和 <5,UP>（远），当前楼层 1→ 优先处理 2（最近），再处理 5（次近），符合 “先到先服务 + 就近响应” 结合的原则。
3.源码指标
我并没有跑成功代码，所以就对目前自己已写了的部分代码作分析
| 类名 | 代码行数（LOC） | 可执行语句数（EOLOC） | 方法数 | 核心逻辑方法数 |
|---|---|---|---|---|
| Direction（枚举） | 3 | 0（枚举定义） | 0 | 0 |
| ElevatorStatus（枚举） | 4 | 0 | 0 | 0 |
| Elevator（核心类） | 98 | 62 | 16 | 8（请求 / 状态操作） |
| ElevatorScheduler（调度器） | 76 | 45 | 4 | 3（调度核心） |
| Main（主类） | 48 | 30 | 1 | 1（输入 / 调度循环） |
| 总计 | 229 | 137 | 21 | 12 |
复杂度分析（基于 Cyclomatic Complexity）：
方法名 圈复杂度 复杂度说明
Elevator.removeCurrentFloorRequests 3 switch 分支（3 种方向），低复杂度
Elevator.hasRequestAtCurrentFloor 3 逻辑或判断（3 种请求场景），低复杂度
ElevatorScheduler.determineNextDirection 8 多层 if-else 分支（方向判断 + 请求检查），中高复杂度，核心风险点
ElevatorScheduler.hasRequestInDirection 4 循环 + 方向分支，中复杂度
ElevatorScheduler.executeOneStep 4 if 分支（请求检查 + 方向判断），中复杂度
Main.main 4 循环 + 正则匹配分支，中复杂度
代码质量问题：
调度器核心方法复杂度过高：determineNextDirection 包含 8 个分支，逻辑嵌套深，可读性差，维护成本高。
方法职责不单一：executeOneStep 同时处理 “方向决策、移动、停靠”，违反单一职责原则。
未使用的代码冗余：findClosestRequestInDirection 方法被注释，未清理。
四、第二次题目集设计与分析
1.类结构设计
//方向枚举类（规范电梯运行方向）
public enum Direction {
UP, DOWN, IDLE // 上行、下行、空闲
}
//外部请求类（封装外部召梯请求）
public class ExternalRequest {
public ExternalRequest(Integer floor, Direction direction) {}
public Integer getFloor() {}
public Direction getDirection() {}
public boolean equals(Object o) {}
public int hashCode() {}
}
//请求队列类（管理内部 / 外部请求，支持去重）
public class RequestQueue {
private LinkedList
private LinkedList
public RequestQueue() {}
public static RequestQueue getQueueInstance() {}
public void addInternalRequest(int floor) {}
public void addExternalRequest(int floor, Direction direction) {}
public LinkedList
public LinkedList
}
//电梯类（管理电梯基础属性与核心操作）
public class Elevator {
private int currentFloor; // 当前楼层
private Direction direction; // 运行方向
private State state; // 运行状态
private int maxFloor; // 最大楼层
private int minFloor; // 最小楼层
public Elevator(int minFloor, int maxFloor) {}
public boolean isValidFloor(int floor) {}
public void move() {}
public void openDoors() {}
public void closeDoor() {}
public void setDirection(Direction direction) {}
public State getState() {}
}
//控制类（核心调度逻辑，负责电梯运行决策）
public class Controller {
private Elevator elevator; // 关联的电梯实例
private RequestQueue queue; // 关联的请求队列
public Controller(Elevator elevator, RequestQueue requestQueue) {}
public static Controller getControllerInstance(Elevator elevator, RequestQueue requestQueue) {}
public void processRequests() {}
private void determineDirection() {}
private void move() {}
private void removeRequests(int currentFloor) {}
}
//主函数
public class Main {}
类图如下：
2.调度逻辑
我的电梯调度器以 “同向优先、即时换向、就近响应” 为核心，平衡运行效率与响应及时性，通过实时方向校验、就近请求查找、动态队列排序，避免无效折返和请求延迟。但有一些问题，如下：
（1）解决 “方向切换延迟”
输入：初始楼层 1，请求<3,UP>、<2,UP>、<5>优化后调度流程：
确定方向：无初始方向，全局最近请求是 2（UP）→ 方向设为 UP
移动：1→2（输出移动信息），需要停靠 → 开门处理<2,UP>→关门
确定方向：UP 方向仍有请求（3、5）→ 保持 UP
移动：2→3（输出移动信息），需要停靠 → 开门处理<3,UP>→关门
确定方向：UP 方向仍有请求（5）→ 保持 UP
移动：3→4→5（输出移动信息），需要停靠 → 开门处理<5>→关门
确定方向：UP 方向无请求（无更高楼层请求）→ 即时换向（无需等待更远楼层）
检查 DOWN 方向：无请求 → 任务结束
路径：1→2→3→5（仅 3 次移动），避免 “先到 5 再折返 2、3” 的无效路径，解决方向切换延迟。
（2）解决 “请求查找范围错误”
输入：初始楼层 1，请求 <5,UP>（远）、<2,UP>（近）优化后调度流程：
确定方向：全局最近请求是 2（UP）→ 方向设为 UP
移动：1→2（输出移动信息）→ 停靠处理<2,UP>→关门
确定方向：UP 方向仍有请求（5）→ 保持 UP
移动：2→3→4→5（输出移动信息）→ 停靠处理<5,UP>→关门
路径：1→2→5（优先处理最近请求），符合 “先到先服务 + 就近响应”，解决请求查找范围错误。
3.源码指标
我并没有跑成功代码，所以就对目前自己已写了的部分代码作分析
| 类名 | 代码行数（LOC） | 可执行语句数（EOLOC） | 方法数 | 核心逻辑方法数 |
|---|---|---|---|---|
| Direction（枚举） | 3 | 0（枚举定义） | 0 | 0 |
| State（枚举） | 2 | 0（枚举定义） | 0 | 0 |
| ExternalRequest（外部请求） | 35 | 12（构造 + getter+equals/hashCode） | 4 | 0（纯数据封装） |
| RequestQueue（请求队列） | 82 | 48（队列操作 + 优化方法） | 10 | 4（hasRequestInDirection/findClosestRequestInDirection 等核心方法） |
| Elevator（电梯类） | 78 | 35（属性操作 + 移动 / 开关门） | 14 | 3（move/openDoors/closeDoor 核心操作） |
| Controller（控制类） | 125 | 72（调度逻辑） | 9 | 5（processRequests/determineDirection 等核心调度） |
| Main（主类） | 45 | 28（输入处理 + 初始化） | 2 | 1（parseAndAddRequest 请求解析） |
| 总计 | 360 | 195 | 39 | 13 |
| 方法名 | 圈复杂度 | 复杂度说明 |
|---|---|---|
| RequestQueue.hasRequestInDirection | 4 | switch 分支（2 个方向）+ 逻辑或判断（2 种请求类型），中复杂度，逻辑清晰无嵌套 |
| RequestQueue.findClosestRequestInDirection | 6 | switch 分支（2 个方向）+ 集合操作判断（4 个非空校验），中复杂度，核心查找逻辑 |
| RequestQueue.findNearestRequest | 5 | 3 次循环 + 距离比较判断，中复杂度，全局请求查找逻辑 |
| Controller.determineDirection | 5 | if-else 分支（3 种场景）+ 方法调用判断，中复杂度，方向决策逻辑清晰 |
| Controller.moveToTarget | 4 | while 循环 + if 判断（停靠检查），中复杂度，移动逻辑线性 |
| Controller.needStop | 3 | 逻辑或判断（3 种请求场景），低复杂度，停靠条件简单 |
| Main.parseAndAddRequest | 4 | 字符串判断 + 分支（内部 / 外部请求），中复杂度，输入解析逻辑 |
| ExternalRequest.equals | 3 | 类型校验 + 属性比较，低复杂度，数据校验逻辑 |
五、第三次题目集设计与分析
1.类结构设计
//方向枚举类（规范电梯运行方向）
public enum Direction {
UP, DOWN, IDLE // 上行、下行、空闲
}
//外部请求类（封装外部召梯请求）
public class ExternalRequest {
public ExternalRequest(Integer floor, Direction direction) {}
public Integer getFloor() {}
public Direction getDirection() {}
public boolean equals(Object o) {}
public int hashCode() {}
}
//请求队列类（管理内部 / 外部请求，支持去重）
public class RequestQueue {
private LinkedList
private LinkedList
public RequestQueue() {}
public static RequestQueue getQueueInstance() {}
public void addInternalRequest(int floor) {}
public void addExternalRequest(int floor, Direction direction) {}
public LinkedList
public LinkedList
}
//电梯类（管理电梯基础属性与核心操作）
public class Elevator {
private int currentFloor; // 当前楼层
private Direction direction; // 运行方向
private State state; // 运行状态
private int maxFloor; // 最大楼层
private int minFloor; // 最小楼层
public Elevator(int minFloor, int maxFloor) {}
public boolean isValidFloor(int floor) {}
public void move() {}
public void openDoors() {}
public void closeDoor() {}
public void setDirection(Direction direction) {}
public State getState() {}
}
//控制类（核心调度逻辑，负责电梯运行决策）
public class Controller {
private Elevator elevator; // 关联的电梯实例
private RequestQueue queue; // 关联的请求队列
public Controller(Elevator elevator, RequestQueue requestQueue) {}
public static Controller getControllerInstance(Elevator elevator, RequestQueue requestQueue) {}
public void processRequests() {}
private void determineDirection() {}
private void move() {}
private void removeRequests(int currentFloor) {}
}
//乘客类
public class Passenger {
private int sourceFloor; // 请求源楼层（外部请求的发起楼层，内部请求则无意义）
private int destFloor; // 目的楼层
public Passenger(int sourceFloor, int destFloor) {
this.sourceFloor = sourceFloor;
this.destFloor = destFloor;
}
public int getSourceFloor() {
return sourceFloor;
}
public int getDestFloor() {
return destFloor;
}
}
//主函数
public class Main {}
类图如下：
2.调度逻辑
本次电梯调度以 “同向优先、就近响应、即时换向” 为核心原则，通过动态方向决策、同方向请求优先处理、就近请求精准匹配，避免无效折返和请求延迟，同时适配 “外部请求转内部目的楼层” 的业务规则（外部请求处理后，其目的楼层自动加入内部队列），平衡运行效率与响应及时性。但有一些问题，如下：
（1）解决 “方向切换延迟”
输入条件
初始状态：当前楼层 1，最小楼层 1，最大楼层 20
请求序列：<2,6>（外部请求：源 2→目的 6）、<5>（内部请求：目的 5）
优化后调度流程
首次方向决策：无初始方向（IDLE），全局查找最近请求
所有请求的 “触发楼层”（外部 = 源楼层，内部 = 目的楼层）：2、3、5
最近触发楼层为 2（距离 1 层），其对应外部请求的目的楼层 6>2，方向判定为 UP；
移动与停靠处理：
移动：1→2（输出：Current Floor: 2 Direction: UP），触发楼层匹配→开门；
处理：移除外部请求 <2,6>，将目的楼层 6 加入内部队列；
关门（输出：Close Door）；
二次方向决策：当前方向 UP，检查同方向是否有未处理请求
外部请求：内部请求：5、6（均 > 2，UP 方向）→ 保持 UP；
移动与停靠处理：
移动：2→3（输出：Current Floor: 3 Direction: UP），触发楼层匹配→开门；
处理：移除外部请求<3,8>，将目的楼层 8 加入内部队列；
关门（输出：Close Door）；
三次方向决策：当前方向 UP，同方向仍有请求（5、6、8）→ 保持 UP；
移动与停靠处理：
移动：3→4（输出：Current Floor: 4 Direction: UP）→ 无触发楼层，不停靠；
移动：4→5（输出：Current Floor: 5 Direction: UP），触发楼层匹配→开门；
处理：移除内部请求 <5>；
关门（输出：Close Door）；
四次方向决策：当前方向 UP，同方向仍有请求(6、8）→ 保持 UP；
移动与停靠处理：
移动：5→6（输出：Current Floor: 6 Direction: UP），触发楼层匹配→开门；
处理：移除内部请求 <6>（来自 < 2,6 > 的目的楼层）；
关门（输出：Close Door）；
五次方向决策：当前方向 UP，同方向仍有请求(8）→ 保持 UP；
移动与停靠处理：
移动：6→7（输出：Current Floor: 7 Direction: UP）→ 无触发楼层，不停靠；
移动：7→8（输出：Current Floor: 8 Direction: UP），触发楼层匹配→开门；
处理：移除内部请求<8>（来自<3,8 > 的目的楼层）；
关门（输出：Close Door）；
最终方向决策：当前方向 UP，检查同方向无更高楼层请求→ 即时换向；
检查 DOWN 方向：无任何未处理请求（外部 / 内部）→ 任务结束。
路径总结
1→2→3→5→6→8（仅 5 次停靠，无无效折返），避免 “先到 8 再折返 2、3、5” 的低效路径，解决方向切换延迟。
（2）解决 “请求查找范围错误”
输入条件
初始状态：当前楼层 1，最小楼层 1，最大楼层 20
请求序列：<5,10>（外部请求：源 5→目的 10，远）、<2,7>（外部请求：源 2→目的 7，近）
优化后调度流程
首次方向决策：无初始方向（IDLE），全局查找最近请求
触发楼层：5、2 → 最近为 2（距离 1 层），目的楼层 7>2，方向判定为 UP；
移动与停靠处理：
移动：1→2（输出：Current Floor: 2 Direction: UP），触发楼层匹配→开门；
处理：移除外部请求 <2,7>，将目的楼层 7 加入内部队列；
关门（输出：Close Door）；
二次方向决策：当前方向 UP，同方向仍有请求（外部 <5,10> 的源 5、内部 7）→ 保持 UP；
移动与停靠处理：
移动：2→3→4→5（输出对应移动信息），触发楼层匹配→开门；
处理：移除外部请求 <5,10>，将目的楼层 10 加入内部队列；
关门（输出：Close Door）；
三次方向决策：当前方向 UP，同方向仍有请求（7、10）→ 保持 UP；
移动与停靠处理：
移动：5→6→7（输出对应移动信息），触发楼层匹配→开门；
处理：移除内部请求 <7>；
关门（输出：Close Door）；
四次方向决策：当前方向 UP，同方向仍有请求（10）→ 保持 UP；
移动与停靠处理：
移动：7→8→9→10（输出对应移动信息），触发楼层匹配→开门；
处理：移除内部请求 <10>；
关门（输出：Close Door）；
最终方向决策：当前方向 UP，无同方向请求→ 即时换向；
检查 DOWN 方向：无未处理请求→ 任务结束。
路径总结
1→2→5→7→10（优先处理近距离请求，再处理远距离请求），符合 “先到先服务 + 就近响应”，解决请求查找范围错误。
3.源码指标
我并没有跑成功代码，所以就对目前自己已写了的部分代码作分析
| 类名 | 代码行数（LOC） | 可执行语句数（EOLOC） | 方法数 | 核心逻辑方法数 |
|---|---|---|---|---|
| Direction（枚举） | 3 | 0（枚举定义，无执行语句） | 0 | 0 |
| State（枚举） | 2 | 0（枚举定义，无执行语句） | 0 | 0 |
| Passenger（乘客类） | 32 | 10（构造器 + getter + equals/hashCode） | 4 | 0（纯数据封装，无业务逻辑） |
| RequestQueue（请求队列） | 48 | 22（队列初始化 + 去重添加 + 队列获取） | 6 | 0（仅基础队列操作，无复杂逻辑方法） |
| Elevator（电梯类） | 65 | 28（属性初始化 + 移动 / 开关门 + 校验） | 12 | 3（move 移动核心、openDoors 开门处理、closeDoor 关门操作） |
| Controller（控制类） | 118 | 68（调度决策 + 移动逻辑 + 请求处理） | 8 | 5（processRequests 总调度、determineDirection 方向决策、move 移动控制、shouldStop 停靠判断、removeRequests 请求移除） |
| Main（主类） | 42 | 25（输入读取 + 解析 + 实例初始化） | 2 | 1（输入解析与请求添加核心逻辑） |
| 总计 | 300 | 153 | 32 | 9 |
| 方法名 | 圈复杂度 | 复杂度说明 |
|---|---|---|
| Controller.determineDirection | 6 | if-else 分支（3 种场景：初始空闲、当前方向有请求、当前方向无请求）+ 双重循环（内部 / 外部请求遍历），中复杂度，方向决策核心逻辑 |
| Controller.move | 5 | while 循环（持续移动）+ if 判断（停靠检查、方向重决策），中复杂度，移动流程线性但包含分支判断 |
| Controller.shouldStop | 4 | 逻辑或判断（内部请求匹配、外部请求源楼层匹配）+ 双重循环（遍历内部 / 外部队列），中复杂度，停靠条件清晰 |
| Controller.removeRequests | 4 | 双重循环（遍历内部 / 外部队列）+ 移除操作判断，中复杂度，请求处理核心逻辑，无深层嵌套 |
| Main 输入解析逻辑（匿名核心逻辑） | 4 | 字符串格式判断 + 分支（内部 / 外部请求）+ 有效性校验，中复杂度，输入解析逻辑清晰 |
| Passenger.equals | 3 | 类型校验 + 双属性比较（源楼层、目的楼层），低复杂度，数据去重校验逻辑简单 |
| Elevator.move | 2 | 方向分支（UP/DOWN）+ 楼层变更，低复杂度，移动操作单一 |
| RequestQueue.addExternalRequest | 3 | 循环遍历去重 + 有效性隐含判断，低复杂度，队列添加逻辑简单 |
六、踩坑心得
1.第一次作业
单类实现踩坑点
请求队列混淆：初期未区分外部上行 / 下行请求队列，直接用一个队列存储，导致 “同向优先” 规则失效 —— 比如电梯上行时会优先处理下方的下行请求。后来拆分外部队列为upExternalQueue和downExternalQueue才解决。
移动逻辑漏判停靠：最初写move方法时，只单纯变更楼层，忘记在每次移动后检查当前楼层是否有请求，导致电梯 “路过” 目标楼层不停车。后续添加 “移动后立即调用停靠检查” 逻辑才修复。
无效请求未过滤：没处理 “请求楼层超过最大 / 最小楼层” 的情况，输入<22>（最大 20）时电梯会异常移动。添加isValidFloor方法校验后，直接忽略无效请求。
2.第二次作业
单一职责拆分踩坑点
类职责边界模糊：刚开始把 “请求去重” 写在Controller里，又在Elevator里加了队列操作，导致类职责混乱。后来明确RequestQueue专属 “请求存储 + 去重”，Controller只做调度，才符合 SRP。
重复请求去重逻辑错误：初期用contains判断重复时，ExternalRequest没重写equals和hashCode，导致相同请求（如<3,UP>两次）无法识别为重复。重写这两个方法，基于 “楼层 + 方向” 比对后解决。
控制类与电梯类耦合过高：Controller直接操作Elevator的私有属性（如currentFloor），修改电梯类时控制类必改。后来给Elevator加getter/setter，通过接口交互解耦。
3.第三次作业
乘客类引入踩坑点
外部请求转内部队列漏处理：忘记 “外部请求处理后（乘客上车），需将目的楼层加入内部队列” 的规则，比如处理<5,4>后，电梯只停 5 楼不开门就走。在openDoors方法里添加 “取出外部请求的目的楼层，调用队列添加内部请求” 逻辑才修复。
乘客类去重逻辑漏洞：内部请求（仅目的楼层）和外部请求（源 + 目的楼层）用同一equals判断，导致<5>（内部）和<3,5>（外部）被误判为重复。后来在equals里加 “源楼层为 null 则只比目的楼层，非 null 则比源 + 目的” 才区分。
方向决策逻辑退化：引入乘客类后，determineDirection方法漏判 “无初始方向时找最近请求”，导致电梯优先处理最远请求（如 1 楼时先去 5 楼再回 2 楼）。添加 “全局遍历请求计算距离，选最近触发楼层” 逻辑后优化。
七、改进建议
1.第一次作业
请求队列混淆：拆分外部请求为upExternalQueue（上行）和downExternalQueue（下行）两个独立队列，调度时优先遍历当前方向对应的外部队列，避免方向混乱。
移动逻辑漏判停靠：电梯每移动 1 层（更新currentFloor后），立即调用checkStop()方法，同步检查内部队列和当前方向外部队列，判断是否需要停靠。
无效请求未过滤：所有请求添加前，先通过isValidFloor(floor)校验（楼层在minFloor~maxFloor之间），无效则直接忽略，不加入队列。
2.第二次作业
类职责边界模糊：明确RequestQueue专属实现 “请求添加、去重、查询”，Controller只调用队列的addXXX()/hasXXX()方法，不直接操作队列内部存储。
重复请求去重失效：给ExternalRequest重写equals()和hashCode()，基于 “楼层 + 方向” 双属性比对（两者都相同才视为重复），确保去重生效。
类耦合过高：Elevator私有属性（currentFloor、direction）只通过getter读取、setter修改，Controller不直接访问，通过接口交互解耦。
3.第三次作业
外部请求转内部队列漏处理：电梯在楼层开门后，遍历外部队列，取出当前楼层的Passenger，调用RequestQueue.addInternalRequest(passenger.getDestFloor())，再移除该外部请求。
乘客类去重逻辑漏洞：Passenger.equals()中补充判断：若一方sourceFloor为 null（内部请求）、另一方非 null（外部请求），直接返回 false；均为 null 则比destFloor，均非 null 则比sourceFloor+destFloor。
方向决策逻辑退化：无初始方向时，遍历所有请求（内部取destFloor，外部取sourceFloor），计算各请求与当前楼层的距离，选距离最近的请求确定初始方向，避免舍近求远。
八、总结
1.收获
本次电梯调度三次阶梯式作业，核心围绕面向对象设计与电梯调度逻辑展开，实现了从单类功能实现到遵循单一职责原则的类拆分、再到乘客类引入优化请求流转的能力提升。学习收获集中在三方面：一是逐步掌握“高内聚、低耦合”的面向对象设计思想，学会通过类拆分、数据封装解决复杂业务问题；二是锤炼了电梯“同向优先、就近响应”的核心调度逻辑，积累了场景化测试与边界问题排查经验；三是掌握了代码去重、解耦、复杂度优化等实用技巧。
2.课程与作业改进建议
提供部分核心测试用例的输入输出示例，帮助我轻松一点完成代码的设计和完成。
3.后续学习目标
多研究程序设计语言的基础用法和算法，锻炼我的代码能力。
-F:\硕士阶段\Java\课程代码\后端\web-ai-code\web-ai-project02\tlias-web-management)
![[数据压缩] LZ4 压缩算法](http://pic.xiahunao.cn/[数据压缩] LZ4 压缩算法)
