一、前言
博主近期疏于学业，故而三次作业均没有完整实现出来，因此这是一篇反思文，同博主一样起步浑浑不清者，可借此文规避一些低效的思路。
（博主依赖ai成瘾，借主播血泪教训，建议读者切忌一味信赖ai！应当试着自己梳理思路，尝试先简单画出类图，然后在scdn等平台查找一些资料参考，最后用ai查漏补缺完善算法。）
三次题目集围绕 “单部电梯调度问题” 展开迭代式设计，核心目标是强化面向对象编程（OOP）思想的实践，从 “单类功能实现” 逐步过渡到 “多类职责拆分与逻辑优化”。以下结合本人实际编码经历，从知识点覆盖、题量设置、难度梯度三个维度展开总结：
（一）知识点覆盖
三次题目集的知识点呈现 “基础→核心→拓展” 的递进关系:
1.基础知识点：类的定义与实例化、枚举类使用、队列数据结构应用（LinkedList）、输入解析与格式校验 —— 本人虽能实现基础语法，但对 “枚举类与业务逻辑的联动”“队列操作的线程安全与效率” 理解不深；
2.核心知识点：单一职责原则（SRP）落地、类间依赖关系设计、调度算法逻辑（同方向优先）—— 本人在题目集 2、3 中虽完成类拆分，但职责边界模糊，调度算法因依赖 AI 生成而完全违反题目规则；
3.拓展知识点：请求过滤机制（无效 / 重复请求）、迭代式重构、外部请求与内部队列联动 —— 本人未实现完整的过滤逻辑，重构时仅修改表面代码，未触及核心逻辑缺陷。
（二）题量与功能迭代
三次题目集均为单道综合编程题，但代码量与功能复杂度显著提升，且迭代需重构而非简单叠加：
| 题目集 | 核心功能要求 | 实现情况 |
|---|---|---|
| 1 | 基础调度（同方向优先、逐楼层移动）、无效楼层过滤 | 类结构符合要求，但重复过滤失效、类交互逻辑混乱 |
| ---- | ---- | ---- |
| 2 | 类拆分（电梯 / 请求 / 队列 / 控制类）、重复请求过滤 | 同上 |
| ---- | ---- | ---- |
| 3 | 新增乘客类、外部请求转内部队列、源 / 目的楼层输入 | 类设计达标，但调度逻辑有问题，只能过第一个测试用例 |
（三）难度梯度
题目集 1：难度低，核心是理解 “同方向优先、逐楼层检查停靠” 规则 —— 因博主未梳理清楚规则，直接用 AI 生成run()方法，导致条件判断嵌套混乱；
题目集 2：难度中等，核心是 “单类拆分为四类” 与 “重复请求过滤”—— 博主虽拆分了类，但未明确类间交互规则（如控制类如何调用队列类），重复过滤仅判断当前队列，未考虑历史请求；
题目集 3：难度高，核心是 “乘客类设计” 与 “外部请求转内部队列”—— 本人盲目照搬 AI 生成的moveToFloor()方法，跳过途中顺路请求，违反题目核心规则。
二、设计与分析（附源码缺陷剖析）
（一）题目集 1：单类设计 ——“职责过载” 的反面教材
- 类设计结构（本人错误设计）
题目集 1 未要求类拆分，博主采用单类设计，但因缺乏规划导致职责混乱：
![image]()
![image]()
错误点：
①direction初始值为 UP（应改为 IDLE）；
②outerQueue未区分上下行；
③processFloor方法内部请求移除逻辑错误。
- 核心逻辑缺陷
processFloor()方法内部请求移除错误
![image]()
错误后果：内部队列若有非队首的顺路请求（如队列[7,5]，不会被移除；且部分场景下未输出 “Close Door”，破坏输出格式。
- 事后反思
第一次作业的单类设计虽快速，但违背 OOP 思想，导致 “牵一发而动全身”。博主当初未绘制逻辑流程图，直接依赖 AI 生成核心方法，既未理解 “同方向优先” 的本质（需遍历同方向所有请求），也未考虑内部请求的 “先到先服务” 与 “顺路处理” 的兼容性。正确的设计应至少拆分出 “请求队列类”，将队列管理与调度逻辑分离。
（二）题目集 2：类拆分 ——“形似神不似” 的单一职责原则
问题点：
①Elevator类仍有hasRequest()等调度相关方法；
②RequestQueue未实现重复请求过滤；
③Controller类未协调好电梯与队列的状态同步。
（三）题目集 3：乘客类迭代 ——“核心逻辑跑偏” 的反面案例
（博主只过了第一个测试点)
测试用例1：（正确）
测试用例2：（错误）
- 类设计结构（博主错误设计）
题目集 3 要求取消请求类、新增乘客类，本人虽创建了Passenger类，但调度逻辑完全违反题目规则：
![image]()
![image]()
问题点：
①Controller类的moveToFloor()方法跳过途中顺路请求；②processSingleRequest()仅处理单个请求，未批量处理同方向请求；
③外部请求转内部队列逻辑不完整。
- 核心缺陷
（1）moveToFloor()方法跳过顺路请求
题目规则：电梯每次移动一个楼层后，需检查是否有顺路请求（内部 + 同方向外部），有则停靠；
本人错误：直接循环移动到目标楼层，途中不检查任何请求，例如电梯从 3 层到 7 层，会直接输出 “4→5→6→7”，跳过 5 层的内部请求，完全违反 “逐楼层检查停靠” 规则。
（2）外部请求转内部队列逻辑不完整
![image]()
错误后果：若当前楼层有多个外部请求（如<5,7>和<5,9>），仅处理request参数对应的一个，其余外部请求未转内部队列，导致遗漏。
3.事后反思
题目集 3 的类设计（Passenger类）是本人唯一达标的部分（AI说的哈哈），但未理解 “同方向优先批量处理” 的本质，导致 “类设计正确，逻辑错误”。这一教训让我明白：类设计是骨架，调度逻辑是灵魂，两者缺一不可。当初若先手动梳理 “同方向优先” 的流程图，再基于流程图编码，绝不会出现 “跳过顺路请求” 的低级错误。
三、总结
1.本人核心问题复盘
- 过度依赖 AI，缺乏自主思考：未手动梳理规则与流程图，导致对逻辑漏洞毫无感知；
- 类设计理解肤浅：仅形式上完成类拆分，未明确职责边界，导致类间耦合度高、逻辑混乱；
- 调度规则理解不透彻：未抓住算法核心逻辑，违反题目规则；
- 细节处理缺失：忽略无效请求过滤、重复请求过滤、状态同步等细节，导致测试用例大面积失败。
2.阶段性学习收获
- 理解 OOP 核心思想：单一职责原则不是 “多创建类”，而是 “每个类只做一件事”，类间通过接口交互，降低耦合；
- 掌握调试技巧：复杂逻辑需通过 “打印关键变量”“断点调试”“绘制流程图” 定位漏洞，而非盲目修改；
- 建立迭代式开发意识：软件设计是持续优化的过程，例如题目集 3 的Passenger类是对题目集 2Request类的优化，需在原有基础上重构，而非推倒重来；
- 认清 AI 的局限性：AI 可辅助语法纠错、代码格式化，但无法替代对业务规则的理解与逻辑梳理，过度依赖只会导致 “代码能跑但不符合要求”。
第一次大作业让我认清了自身的不足：电梯调度问题看似简单，实则是对 OOP 思想、逻辑严谨性、细节处理能力的综合考验。
如若此文能为同样陷入困境的同学提供参考，避免重蹈覆辙，也算功德一件啦。
