三次电梯题目的总结与感悟

一、三次电梯作业回顾：
题目1：单类设计实现基本调度
核心需求：实现单电梯的基本调度逻辑。
考察重点：面向对象基础、状态管理、简单算法设计。
难点：请求队列管理、方向判断、移动逻辑。

题目2：基于SRP原则的迭代设计。
新增要求：拆分职责到多个类（电梯类、请求类、队列类、控制类）
考察重点：单一职责原则、类间协作。
难点：请求过滤逻辑、调度算法优化。

题目3：引入乘客类的增强设计
新增要求：乘客类与请求转换机制。
考察重点：对象协作关系、需求变更适应能力。
难点：请求转换逻辑、多阶段请求处理。

二、各次作业代码问题分析
第一次作业问题分析

 

主要问题：

方向判断逻辑缺陷：仅根据目标楼层判断方向，未考虑运行中可能出现的同方向请求。
请求处理顺序错误：简单合并内外请求后统一排序，违背"同方向优先"原则。
状态管理缺失：没有实现STOP/MOVE状态转换。
楼层有效性验证缺失：未处理超过最大/最小楼层的请求。
输出格式错误：移动过程中每层都输出，但题目要求只在到达目标层时输出。
典型错误场景：
当存在3楼外部上行请求时，电梯从1层移动到3层的过程中不会响应2层的同方向请求。

第二次作业问题分析

 

// 控制器类中的方向判断逻辑
主要问题：
职责划分不合理：
控制器类承担了过多调度逻辑。
请求队列类缺少过滤重复请求的方法。
电梯类包含业务逻辑（isValidFloor）
调度算法缺陷：
仅比较队列首个请求，未扫描所有可能请求。
未实现LOOK算法（电梯到端点自动转向）
重复请求处理缺失：
未实现题目要求的相同请求过滤。
请求处理顺序错误：
外部请求未按方向分组处理。
内部请求未考虑电梯运行方向。
应该优先处理第一个内部请求或第一个外部请求，在第一个内部请求或第一个外部请求处理完以后，后面的请求队列次序-1。
测试用例失败示例：
输入：

1 10
<5,DOWN>
<5,DOWN>
<3>
END
预期应过滤重复的<5,DOWN>，但代码会处理两次

第三次作业问题分析

 

java
// 请求转换逻辑缺失
主要问题：
需求理解偏差：
未将外部请求的目的楼层加入内部队列。
仍然使用旧版请求格式（源楼层+方向）
对象设计缺陷：
乘客类未实际参与业务流程。
请求类未区分内外类型。
方向判断逻辑错误：
根据请求源楼层判断方向，而非目的楼层。
未处理跨层请求（如从5层到3层应下行）
楼层有效性验证缺失：
未检查目的楼层是否合法。
典型错误场景：
输入：
1 20
<5,8>
END

三、共性问题的深度剖析
1. 需求分析阶段
过早编码：未充分理解需求即开始编写代码。
边界条件遗漏：未列出所有可能场景（如最高层只能下行）
示例验证不足：未用题目样例进行完整流程推演。

2. 设计模式应用
违反SRP原则：

缺少领域对象：
未建立Floor、Request等核心领域模型。
业务逻辑分散在多个类中。

3. 算法实现问题
方向判断逻辑缺陷：
graph TD
A[当前楼层] --> B{有上行请求?}
B -->|是| C[保持上行]
B -->|否| D{有下行请求?}
D -->|是| E[转向下行]
D -->|否| F[保持静止]
实际代码中缺失完整的状态转换机制
请求扫描效率低下：
应优化为只扫描第一个内部请求和第一个外部请求。

4. 测试验证不足
未建立测试用例集：
text
Case01: 基础上升请求
Case02: 跨越楼层请求
Case03: 重复请求过滤
Case04: 边界楼层测试
...
缺乏自动化测试：
四、改进方案与最佳实践
1. 领域模型重构
Elevator --> RequestQueue : 查询
Controller --> Elevator : 控制
Controller --> RequestQueue : 管理
2. 调度算法优化
java
// 改进的LOOK算法实现

3. 请求处理优化

应该优先处理第一个内部请求或第一个外部请求，在第一个内部请求或第一个外部请求处理完以后，后面的请求队列次序-1。

4. 状态管理改进

五、学习收获与感悟
1. 软件工程原则的具象化
单一职责原则的实践价值：当修改方向判断逻辑时，只需要改动Controller类。
开闭原则的重要性：通过继承Request实现不同类型请求的扩展。

2. 算法与工程的平衡
从理论上的LOOK算法到实际代码的转化：
text
理论模型 -> 状态转换图 -> 边界条件处理 -> 异常处理
3. 调试能力的提升
使用日志分析工具：
4. 工程思维的培养
版本控制：应使用Git管理三次迭代。
持续集成：建立自动化测试流水线。

六，总结：
在参与这三次电梯作业的过程中，我对软件工程的认知产生了翻天覆地的变化。起初，我单纯地将软件工程等同于编写代码，认为只要能实现功能，程序就算合格。然而，随着项目的推进，我逐渐意识到，软件工程远比想象中复杂得多，它不仅要求我们具备扎实的编程技能，更需要建立起一套完整的工程化思维体系。
每一次需求变更，都像是一场突如其来的挑战，考验着系统设计的合理性与灵活性。当新的需求出现时，我曾手忙脚乱，发现原有的设计无法轻松容纳这些变化，甚至牵一发而动全身，导致整个系统陷入混乱。这让我明白，优秀的软件设计必须具备前瞻性和扩展性，要能够预见未来可能出现的需求变化，提前做好架构规划。
而每一个 bug 的出现，也不再是令人沮丧的挫折，反而成为了我改进设计的宝贵机会。通过深入分析 bug 产生的原因，我不仅修复了当前的问题，还进一步优化了代码结构，完善了系统的逻辑。在这个过程中，我学会了如何从错误中吸取教训，如何通过反思和总结提升自己的能力。
在持续的重构过程中，我逐渐理解了软件工程的真谛。它不仅仅是代码的堆砌，更是一个不断优化、迭代的过程。每一次重构，都是对自己技术能力和思维方式的挑战与提升。我期待着在未来的学习和工作中，能够继续保持这种不断探索、持续改进的精神，在软件工程的道路上不断前行，成长为一名真正优秀的软件工程师，为打造高质量的软件产品贡献自己的力量。