电梯调度

前言
知识点：三次大作业的代码主要涉及到类封装、内部静态类、构造方法、访问控制修饰符；运用 LinkedList 实现 Queue 的 FIFO 操作、ArrayList 存储 / 遍历请求，List 连续重复元素过滤；流程控制涉及多场景 while/for 循环、条件判断，以及输入不匹配、类型转换等异常捕获；字符串处理包含切割、截取、格式化校验；输入输出通过 Scanner 读取控制台指令、打印电梯运行日志；业务逻辑上实现电梯状态管理、运行方向动态调整、内 / 外部请求优先级处理，整体知识点围绕基础语法与简单业务逻辑设计展开。
题量及难度：核心考点包括，覆盖面向对象（类封装、内部类）、集合框架（Queue/List 操作、去重）、流程控制（循环 / 条件 / 异常）、字符串处理（切割 / 校验）、输入输出、业务逻辑设计六大模块，考点密度适配 Java 入门级实验要求。整体难度为中等，基础语法（变量、循环、类定义）偏简单，集合操作、异常处理为简单 - 中等，核心难点集中在电梯运行方向动态调整、请求停靠规则及输入解析容错

设计与分析

第一次作业分析：该电梯调度模拟代码的核心逻辑围绕 “请求接收 - 方向决策 - 楼层移动 - 停靠处理” 的闭环展开，遵循 “内部请求优先、定向连续运行、按序处理请求” 的核心调度规则，整体逻辑可拆解为五大核心模块，各模块环环相扣形成完整的电梯运行模拟。
优先级原则：内部请求（轿厢内选层）> 外部请求（楼层呼叫），电梯优先响应轿厢内指令；
定向运行原则：电梯一旦确定运行方向（UP/DOWN），会持续朝该方向移动，直到该方向无待处理请求，再切换方向或停止；
FIFO 原则：所有请求按 “先进先出” 顺序处理，未做复杂的请求排序或优先级重排；
容错原则：输入解析、请求添加环节均做合法性校验，异常请求直接跳过，保证程序稳定性。
基于SourceMonitor的源代码分析

从图中可以得到
这份代码指标分析从多维度量化了电梯调度模拟代码的质量：代码规模上，总行数 192 行、可执行语句 94 行，分支语句占比 24.5%，方法调用语句 49 行，注释占比 13.0%，整体规模适配入门级实验需求；结构层面，包含 2 个类，每类平均 3 个方法、每方法平均 13 条语句，方法粒度均衡；复杂度方面，最大方法复杂度 15（集中在 Main.main ()）、平均 8.0，处于中等可维护区间；代码块深度以 1 层嵌套为主，最深 5 层无超 6 层嵌套，结构可控。可视化图表也印证代码各维度分布均衡，仅 Main.main () 因输入解析分支多导致复杂度和深度偏高。

第二次作业分析：Elevator类的所有属性、方法（构造方法、请求添加、停靠判断、方向决策、运行逻辑等）均与基础版一致，核心调度规则未变：
内部请求优先级 > 外部请求；
电梯定向运行，仅按队头请求判断方向；
外部请求需 “楼层匹配 + 方向一致 / 内部无请求” 才停靠；
所有请求按 FIFO 处理，保留非连续重复请求
新增核心功能：连续重复请求过滤
第二次电梯调度程序对于第一次电梯调度算法进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP）
类图如图所示

基于SourceMonitor的源代码分析：

代码规模上，总行数 213 行，可执行语句 105 行，分支语句占比 24.8%，方法调用语句 57 行，注释占比 13.1%，整体规模适配实验代码需求。结构层面，包含 2 个类，每类平均 3 个方法，每方法平均 14.83 条语句，方法粒度均衡。复杂度方面，最大方法复杂度仅 1（集中在Elevator.ExternalRequest()），平均复杂度 1.00，嵌套最深 4 层，整体结构简单易维护。可视化图表显示各维度分布均衡，无复杂逻辑或深嵌套问题。

第三次作业分析：第三次代码是高内聚、低耦合的面向对象电梯调度系统，在基础版逻辑上进行了深度重构：通过枚举、多类拆分、职责分层，实现了 “数据封装 - 队列管理 - 电梯控制 - 调度逻辑” 的解耦，新增乘客实体、方向 / 状态枚举，优化了请求处理和输入校验逻辑，整体架构更贴近工程化开发规范。该版本代码相较于前两段基础版电梯调度代码，核心区别体现在架构设计、数据模型、职责拆分、场景适配四大维度，是从 “基础功能模拟” 到 “工程化结构化实现” 的全面升级
类图如图所示

基于SourceMonitor的源代码分析：

指标分析显示：代码总行数 407 行、可执行语句 158 行，因分层设计规模较基础版大幅增加，但分支语句占比 17.1%、方法调用语句 79 行，模块化程度高。结构上包含 5 个类 / 枚举，每类平均 3.6 个方法、每方法平均 8.44 条语句，方法粒度精细；复杂度层面，最大方法复杂度仅 3、平均 1.5，处于低复杂度区间，代码块嵌套最深 5 层且深嵌套占比低。可视化图表印证各维度分布均衡，注释占比 20.4% 更易理解。相比基础版，该代码以规模增加换结构合理性，分层设计使单方法逻辑简化，复杂度、嵌套深度显著降低。

踩坑心得
第一次作业：编写基础版电梯调度代码时，核心踩坑点集中在逻辑耦合与边界校验缺失。首先，将电梯物理属性（楼层、方向）与调度逻辑（方向决策、停靠判断）全部封装在Elevator类中，导致后续修改调度规则时，需频繁改动核心类，违背 “单一职责”；其次，外部请求仅校验楼层和方向格式，未过滤 “源楼层 = 目的楼层” 的无效请求，运行时出现电梯无意义停靠；另外，方向判断依赖字符串常量（"UP"/"DOWN"），因大小写输入错误导致调度逻辑失效，且嵌套判断（如needStop()中多层 if）未做拆解，调试时难以定位逻辑漏洞。这让我意识到，即使是基础功能实现，也需提前做好职责拆分和基础的类型安全、边界校验设计。

第二次作业：在基础版上新增连续重复请求过滤功能时，主要踩坑点是过滤逻辑的局限性与耦合性。首先，过滤方法仅基于字符串完全匹配去重，未考虑请求语义等价性（如<5,up>和<5,UP>被判定为不同请求），导致过滤效果不达预期；其次，过滤方法直接写在Main类中，与请求解析逻辑紧耦合，后续若修改请求格式，需同步改动过滤方法；此外，新增过滤逻辑后未补充单元测试，上线后发现过滤空列表时因未判空导致空指针异常。这提醒我，新增功能时需兼顾 “语义合理性” 与 “代码解耦”，且任何逻辑新增都要覆盖边界场景测试。

第三次作业：重构为工程化进阶版代码时，核心踩坑点在于过度设计与嵌套优化不足。首先，为追求 “架构完整” 新增State枚举却未实际使用，造成代码冗余；其次，ElevatorController的handleCurrentFloor()方法中，外部请求处理仍保留多层嵌套 if（源楼层匹配→内部队列判空→方向匹配），虽拆分了类但未优化嵌套逻辑，调试时仍需逐层排查；另外，依赖注入仅做到 “构造器传参”，未抽象接口，后续替换调度算法时仍需修改控制器代码。这让我认识到，工程化重构需避免 “为设计而设计”，在分层解耦的同时，要聚焦核心逻辑的嵌套简化，且抽象设计需匹配实际扩展需求，而非过度预留接口。

改进建议
第一次作业：核心问题为职责混杂、类型不安全、嵌套深。改进需拆分Elevator类，将调度逻辑剥离为ElevatorController，仅保留物理属性管理；用枚举替代方向字符串，避免输入错误；增强边界校验，过滤源 / 目的楼层相同的无效请求；拆分needStop()嵌套判断为独立方法，降低层级。改进后代码耦合度降低，类型安全提升，核心逻辑更清晰，调试效率显著提高。

第二次作业：核心问题是过滤逻辑局限、耦合高、边界覆盖不足。需重构过滤方法，基于请求语义（楼层 + 方向）去重，而非字符串匹配；将过滤逻辑封装为RequestFilter工具类，解耦主流程；补充空列表、异常格式等边界测试，增加空指针校验；预留过滤规则扩展接口。改进后过滤效果贴合业务，代码复用性提升，运行时异常风险降低。

第三次作业：核心问题是过度设计、嵌套未优化、扩展成本高。需删除未使用的State枚举，简化冗余代码；用卫语句替代handleCurrentFloor()嵌套 if，降低层级；抽象ElevatorScheduler接口，实现调度算法灵活替换；拆分Main类输入解析为独立方法。改进后代码轻量化，嵌套深度降低，扩展能力提升，符合工程化开发规范

总结
1.学到的核心内容
从基础版的 “功能实现优先”，到过滤版的 “细节优化”，再到进阶版的 “工程化设计”，逐步理解面向对象设计的核心：单一职责、低耦合高内聚，学会用枚举、多类拆分解耦代码；
掌握了队列、异常处理、输入校验等基础语法的实际应用，理解业务逻辑（如电梯定向运行、请求优先级）与代码实现的结合方式；
认识到代码指标（复杂度、嵌套深度）对可维护性的影响，学会通过方法拆分、卫语句等优化代码结构。
2.需进一步学习研究的方向
调度算法层面：目前仅实现 FIFO 调度，需深入学习 SCAN、LOOK 等实际电梯调度算法，结合场景优化请求处理效率；
工程化层面：进阶版虽做了分层，但未抽象接口、未引入设计模式（如策略模式适配不同调度算法），需研究设计模式在实际项目中的落地；
实战能力层面：缺乏单元测试、多线程实时请求处理的实现，需学习 Junit 测试、多线程编程，提升代码的健壮性和实用性；
代码优化层面：对复杂度、嵌套深度的优化仅停留在基础方法拆分，需深入学习代码重构技巧，结合工具（如 SonarQube）量化分析并优化代码质量。