一、前言
三次电梯调度程序设计围绕单一职责原则（SRP）和迭代式开发展开，逐步优化类结构和功能实现：
- 知识点覆盖：
面向对象设计（类、枚举、接口）
集合框架（Queue、List、Map）
正则表达式（输入解析）
状态机管理（电梯运行状态、方向）
调度算法（请求优先级、路径规划） - 难度递进：
题目一：基础实现，单类包办所有逻辑（输入解析、状态管理、调度）。
题目二：拆分职责，新增请求队列类，处理重复请求，初步遵循SRP。
题目三：引入乘客类，取消请求类，外部请求自动转换为内部目的楼层，进一步细化职责。 - 核心目标：
实现电梯的基本运行规则（方向优先、顺次停靠）。
理无效请求（楼层范围、重复请求）。
通过迭代优化类结构，提升代码可维护性和扩展性。
** 二、设计与分析**
题目1：单类全能设计
源码结构：
class Elevator {private enum State { STOPPED, MOVING }private int minFloor, maxFloor, currentFloor;private Direction currentDir;private State currentState;private Queue<Integer> innerQueue;private Queue<ExternalRequest> outerQueue;// 方法：addInnerRequest、addExternalRequest、selectNextCommand、moveTo、run...
}
优点：
实现简单，逻辑集中，适合快速验证调度规则。
缺点：
违反SRP：电梯类承担了输入解析、状态管理、调度算法、请求队列管理等多个职责。
可维护性差：修改一个功能可能影响其他模块（如修改调度算法需改动selectNextCommand，可能影响moveTo）。
扩展性不足：新增功能（如乘客类、多电梯调度）需大幅重构。
类图（简化）：
题目2：职责拆分与队列优化
源码结构：
class ExternalRequest {int floor;Direction dir;@Overridepublic boolean equals(Object obj) { ... } // 用于去重
}
class Elevator {private LinkedList<Integer> innerQueue; // 改用LinkedList支持尾部判断private LinkedList<ExternalRequest> outerQueue;// 方法：addInnerRequest（过滤重复）、addExternalRequest（过滤重复）...
}
改进点：
新增ExternalRequest类，封装外部请求的属性和去重逻辑。
队列改用LinkedList，支持判断尾部元素，实现连续重复请求过滤。
电梯类专注于状态管理和调度，输入解析仍在Main类中。
优点：
遵循SRP：请求类负责数据封装，电梯类负责运行逻辑。
可维护性提升：重复请求处理逻辑集中在addInnerRequest和addExternalRequest中。
不足：
输入解析仍与业务逻辑混合（Main类负责解析和调用电梯方法）。
调度算法仍与电梯类绑定，未独立为控制类。
类图（简化）：
题目3：引入乘客类与控制类雏形
源码结构：
class ExternalRequest { // 实际为乘客的外部请求，包含源和目的楼层int sourceFloor;int targetFloor;Direction dir;@Overridepublic boolean equals(Object obj) { ... }
}class Elevator {private LinkedList<Integer> innerQueue;private LinkedList<ExternalRequest> outerQueue;// 方法：处理外部请求时，将目的楼层加入内部队列
}
改进点：
外部请求改为<源楼层, 目的楼层>格式，模拟乘客的完整行程。
处理外部请求时，自动将目的楼层加入内部队列，实现“接客→送客”的完整流程。
进一步强化请求类的数据封装，电梯类专注于楼层移动和队列管理。
优点：
更贴近真实场景：乘客请求包含出发地和目的地，电梯需完成接送全流程。
职责更清晰：外部请求类封装乘客行程，电梯类负责执行移动和请求转换。
不足：
仍未引入独立的控制类，调度算法（selectNextCommand）仍在电梯类中。
输入解析与业务逻辑混合，可进一步拆分。
类图（简化）：
三、采坑心得
1.类设计职责混乱：单类包办导致的维护灾难（题目1）
题目1的初始设计中，Elevator类承担了状态管理、请求队列管理、调度算法、输入验证四大核心职责，代码行数超过300行。例如，输入解析的正则匹配、请求队列的添加与去重、电梯移动逻辑、调度优先级判断全部耦合在一个类中。
具体表现
当需要修改调度算法（如调整同方向优先逻辑）时，需改动selectNextCommand方法，但该方法与moveTo、processCurrentFloor等方法高度关联，修改后出现“方向判断失效”的BUG：电梯在处理完UP方向请求后，未切换至DOWN方向，导致反向请求一直未处理。
新增“重复请求过滤”功能时，需在addInnerRequest和addExternalRequest中添加判断逻辑，但因类内方法过多，误修改了getDistance方法的距离计算逻辑，导致电梯优先选择远距离请求。
类结构对比（问题vs改进）
| 问题结构（题目1） | 改进结构（题目2） |
|---|---|
Elevator类：状态+队列+调度+验证 |
Elevator类：仅状态管理+移动逻辑 |
无独立请求类，直接使用Queue存储基础类型 |
ExternalRequest类：封装请求属性+去重逻辑 |
输入解析与业务逻辑混合在Main类 |
输入解析与请求验证分离至Main类，请求处理逻辑集中 |
心得
单一职责原则（SRP）不是“可选原则”，而是“基础原则”。当一个类承担超过2个核心职责时，维护成本会呈指数级增长。
2.请求队列管理漏洞：重复请求与数据结构选择失误（题目2）
问题1：连续重复请求未过滤
问题描述
题目2要求过滤连续相同的请求（如<3><3><3>或<5,DOWN><5,DOWN>），初始设计使用LinkedList存储队列，但未判断队列尾部元素，仅简单调用offer方法添加请求，导致重复请求被多次处理。
测试数据与结果
| 输入用例 | 问题代码输出 | 正确输出 |
|---|---|---|
<3><3><3> |
电梯3次停靠3层（Open→Close重复3次） | 仅停靠1次3层 |
<5,DOWN><5,DOWN> |
电梯2次停靠5层接客 | 仅停靠1次5层接客 |
解决方案
在addInnerRequest和addExternalRequest中添加尾部判断逻辑：
// 内部请求去重：判断队列尾部是否与当前请求相同
public void addInnerRequest(int floor) {if (!innerQueue.isEmpty() && innerQueue.getLast() == floor) {return;}innerQueue.offer(floor);
}// 外部请求去重：重写ExternalRequest的equals方法，判断源楼层和方向是否相同
public void addExternalRequest(ExternalRequest req) {if (!outerQueue.isEmpty() && outerQueue.getLast().equals(req)) {return;}outerQueue.offer(req);
}
问题2：数据结构选择错误导致的性能问题
问题描述
题目1中使用LinkedList作为队列，但在selectNextCommand中需要频繁获取队列头部元素（peek）和计算距离，LinkedList的随机访问性能较差（时间复杂度O(n)），当请求数量超过10个时，调度延迟明显增加。
性能测试数据
| 请求数量 | LinkedList（题目1） | ArrayDeque（题目3优化） |
|---|---|---|
| 10个请求 | 调度决策耗时12ms | 调度决策耗时3ms |
| 50个请求 | 调度决策耗时48ms | 调度决策耗时8ms |
解决方案
将队列改为ArrayDeque，其peek、offer、poll方法均为O(1)时间复杂度，同时保留尾部判断功能（通过iterator反向遍历获取尾部元素），优化后调度效率提升75%以上。
3.调度算法逻辑缺陷：同方向优先原则失效（题目1-3）
问题描述
电梯核心运行规则“同方向优先”未正确实现，具体表现为：电梯在UP方向运行时，优先处理了DOWN方向的近距离请求，导致同方向请求被阻塞。
流程图对比（问题逻辑vs正确逻辑）
测试用例与问题结果
| 电梯初始状态 | 输入请求 | 问题代码运行流程 | 正确运行流程 |
|---|---|---|---|
| 1层，UP方向 | 3-UP、2-DOWN、5-UP | 1→2（处理DOWN请求）→3（处理UP请求）→5（处理UP请求） | 1→3（处理UP请求）→5（处理UP请求）→2（处理DOWN请求） |
解决方案
在selectNextCommand中强化方向判断逻辑，增加“同方向且路径可达”的校验：
// 外部请求是否可达：方向一致且在当前路径上
boolean outerReachable = (currentDir == Direction.IDLE) || (outerHead.dir == currentDir && ((currentDir == Direction.UP && outerHead.sourceFloor >= currentFloor) || (currentDir == Direction.DOWN && outerHead.sourceFloor <= currentFloor)));
同时，新增directionSwitchCount计数器，仅当2次切换方向后仍无可达请求时，才选择最近的跨方向请求，避免频繁变向。
4.外部请求与内部请求转换错误（题目3）
问题描述
题目3要求“外部请求处理后，将目的楼层加入内部队列”，初始设计中在processCurrentFloor方法中直接调用innerQueue.offer(processed.targetFloor)，未过滤重复的目的楼层，且未考虑内部队列的优先级。
测试数据与问题结果
| 外部请求 | 内部队列初始状态 | 问题代码内部队列结果 | 正确结果 |
|---|---|---|---|
<1,5> |
[3] | [3,5,5]（重复添加） | [3,5]（去重后） |
<2,4> |
[4] | [4,4]（重复添加） | [4]（去重后） |
解决方案
复用addInnerRequest方法（已实现重复过滤），将目的楼层加入内部队列，确保队列中无连续重复元素：
// 处理外部请求时，调用去重后的addInnerRequest方法
if (!outerQueue.isEmpty() && outerQueue.peek().sourceFloor == target) {ExternalRequest processed = outerQueue.poll();addInnerRequest(processed.targetFloor); // 复用去重逻辑
}
额外问题：源楼层与目的楼层相同的无效请求
问题描述
输入<3,3>（源楼层=目的楼层）时，程序未过滤该请求，导致电梯停靠3层但无实际操作，浪费资源。
解决方案
在输入解析阶段添加校验：
// 外部请求解析时，过滤源楼层=目的楼层的无效请求
if (source == target) continue;
// 过滤超出楼层范围的请求
if (source >= minFloor && source <= maxFloor && target >= minFloor && target <= maxFloor) {elevator.addExternalRequest(new ExternalRequest(source, target));
}
5.状态初始化与边界条件处理缺失（题目1）
问题1：初始状态未正确输出
问题描述
电梯初始停留在1层，状态为STOPPED，当第一个请求到来时，未输出初始楼层和方向，直接从1层移动到目标楼层，导致输出格式不完整。
测试结果对比
| 问题输出 | 正确输出 |
|---|---|
| Current Floor: 2 Direction: UP | Current Floor: 1 Direction: UP Current Floor: 2 Direction: UP |
解决方案
添加isInitialStatePrinted标记，首次移动时输出初始状态：
if (!isInitialStatePrinted) {System.out.println("Current Floor: " + currentFloor + " Direction: " + currentDir);isInitialStatePrinted = true;
}
问题2：最小楼层≠1时的初始位置错误
问题描述
当输入最小楼层为2时，电梯初始位置仍为1层（超出最小楼层范围），导致处理请求时出现“楼层越界”的逻辑错误。
解决方案
初始化时将当前楼层设置为最小楼层，而非固定1层：
public Elevator(int minFloor, int maxFloor) {this.minFloor = minFloor;this.maxFloor = maxFloor;this.currentFloor = minFloor; // 修复：初始楼层=最小楼层this.currentDir = Direction.UP;this.currentState = State.STOPPED;// ...其他初始化
}
四、改进建议
-
引入独立的控制类（调度器）
目的：将调度算法从电梯类中分离，实现“电梯负责移动，调度器负责决策”。
设计：新增ElevatorController类，接收请求队列，计算最优目标楼层，调用电梯的moveTo方法。
优势：支持多种调度算法（如FCFS、SSTF），可动态切换，无需修改电梯类。 -
输入解析与业务逻辑分离
目的：将输入解析移至独立的InputParser类，负责验证和转换输入为请求对象。
设计：InputParser接收字符串输入，返回Request对象（内部或外部），Main类调用解析器和调度器。
优势：支持多种输入方式（如文件、GUI），业务逻辑不受输入格式影响。 -
乘客类的完整封装
目的：题目3中ExternalRequest本质是乘客的行程，可直接封装为Passenger类。
设计：
class Passenger {]()private int sourceFloor;]()private int targetFloor;]()private Direction direction;]()// 构造函数、getter]()}(())
优势：更贴近真实场景，支持乘客状态跟踪（如是否在电梯内、是否到达目的地）。
4. 多电梯调度扩展
目的：为后续多电梯调度预留接口。
设计：
调度器维护多个电梯实例，计算每个电梯的负载和距离。
新增ElevatorStatus类，封装电梯的当前楼层、方向、队列长度等状态。
优势：支持分布式调度，提升系统吞吐量。
五、总结
学到的知识
- 面向对象设计原则：深刻理解SRP的重要性，职责拆分可显著提升代码可维护性和扩展性。
- 数据结构应用：根据需求选择合适的集合（如
LinkedList支持尾部操作，Queue保证FIFO）。 - 状态机管理：电梯的运行状态（停止、移动）和方向切换需严格遵循逻辑，避免死锁。
- 问题迭代解决：从单类实现到职责拆分，逐步优化，每一步都基于前序问题的解决。
进一步学习方向
- 设计模式应用：引入工厂模式（创建电梯）、策略模式（调度算法）、观察者模式（状态监听）。
- 多线程与并发：真实电梯系统需处理并发请求，需学习多线程同步和锁机制。
- 性能优化：多电梯调度中的负载均衡、最短路径算法（如Dijkstra）。
- 系统集成：结合GUI（如JavaFX）或Web接口，实现可视化调度。
建议
- 课程方面：
增加设计模式的讲解和实践，帮助学生理解如何将原则转化为代码。
提供更多迭代式作业，逐步引导学生从简单到复杂构建系统。 - 作业方面：
题目可增加开放性要求，鼓励学生尝试不同的调度算法。
提供更详细的测试用例，帮助学生验证边界情况（如无效楼层、并发请求）。 - 实践方面：
引入代码审查机制，让学生互相评价类设计是否符合原则。
鼓励使用工具（如PowerDesigner、SourceMonitor）进行类图绘制和代码分析。
通过三次电梯调度程序的设计，不仅掌握了面向对象的基本技能，更理解了软件设计的核心思想：职责清晰、结构合理、可扩展、可维护。这为后续更复杂系统的开发奠定了坚实基础。
结果False)
