NCHU 电梯分析———第一次blog
一.前言及设计分析
3次题目的知识点：
question1:
1 PassengerRequest 类：表示乘客请求，包含请求的楼层和方向。
2 RequestQueue 类：管理乘客请求队列，包括内部请求队列和外部上下行请求队列，提供添加请求的方法。
3 Elevator 类：表示电梯，包含电梯的基本属性和操作，如移动到指定楼层、处理楼层请求等。
4 ElevatorController 类：负责电梯的调度控制，根据请求队列和电梯当前状态，决定电梯的运行方向和停靠楼层。
5 Main 类：读取用户输入，创建电梯和控制器对象，处理用户请求并启动电梯调度。在处理请求时，会检查请求楼层是否有效以及是否为重复请求，若为无效或重复请求则忽略。
分析：电梯属性状态：需设计电梯类，涵盖最大、最小楼层，当前楼层，运行方向和状态等属性，能对这些状态进行更新和记录。
请求队列：分别管理电梯内、外乘客请求队列，外部请求区分上行和下行，可添加、处理请求。
运行规则：电梯初始在 1 层静止，有请求时启动。运行时优先处理同向请求，完后处理反向请求。到达楼层检查有无请求，有则开关门处理，无则继续运行。
输入处理：键盘模拟乘客请求输入，要识别内、外部请求格式，处理无效楼层等错误请求，无请求时电梯保持静止。
question2:
1 封装 2单一职责原则（SRP）：
3 定义了多个类，并通过构造函数初始化对象的属性。例如，PassengerRequest 类的构造函数 PassengerRequest(int floor, String direction) 用于设置请求的楼层和方向；Elevator 类的构造函数 Elevator(int minFloor, int maxFloor) 初始化电梯的最小楼层、最大楼层等属性。
在 Main 类中创建了 Elevator 和 ElevatorController 等类的对象，并调用它们的方法来实现电梯调度的功能，体现了类的实例化和对象的交互。
4 集合框架（java.util.List）：
RequestQueue 类中使用 List 接口（具体实现为 ArrayList）来存储乘客请求队列，包括内部请求队列 internalRequests、外部上行请求队列 upExternalRequests 和外部下行请求队列 downExternalRequests。
利用 List 的方法（如 add、contains、removeIf 等）来管理请求队列，实现添加请求、检查请求是否存在以及移除请求等操作。
控制流语句：
5 if 条件语句：用于判断各种条件，如判断请求楼层是否有效
while 循环：在 ElevatorController 的 run 方法中使用 while 循环来持续处理请求队列，直到所有请求都被处理完；在读取用户输入时也使用 while 循环来不断接收请求，直到输入 end 为止。
分析；本次需求是对之前的电梯调度程序进行迭代设计，通过加入Passenger类并取消PassengerRequest类，来优化程序结构，同时遵循单一职责原则（SRP），确保每个类只负责一项明确的功能。要实现一个完整的电梯调度模拟程序，模拟电梯响应乘客请求的运行过程。
详细需求分析：
question3:
1 同样涉及封装 多态 继承 字符串处理 和list集合使用。
二.采坑心得：
要养写代码注释的习惯，尤其是复杂度逻辑部分。题目一定要仔细阅读以防做无用功。通过完成题目集 5 至 7 的练习，在面向对象编程方面有了更深入的理解和实践。学会了如何运用单一职责原则进行类的设计，将复杂的功能模块拆分成多个职责明确的类，提高了代码的质量和可维护性。在处理电梯调度问题的过程中，锻炼了逻辑思维能力和问题解决能力，学会了如何分析问题、设计算法并通过编程实现。
这几次中最难的应该算第一次了，因为后两次基本上是迭代核心逻辑没变，第一次做的时候真是很折磨感觉真是做不出来，在投入大量时间后，慢慢变得得心应手了些，到最后测试点通过的喜悦。
在学习过程中，也发现了自己的不足之处。对于算法的掌握不足在碰到这种难题时很难独自处理，这几次题目集真的是一次很大的挑战，也反映了上学期C语言基础功不扎实，在今后的学习中需多加练习和培养这方面的思维，提高动手能力。
三.改进建议：
对代码结构、可读性、性能等方面暴露出的问题，结合软件开发最佳实践，提出以下创新性改进方案，既保证技术有效性，又降低与常规建议的重复度。
one 架构设计革新
- 功能模块解耦策略
摒弃传统将所有调度逻辑集中于单一Controller类的做法，采用微服务化拆分思路。将电梯调度系统划分为请求解析中心、智能调度引擎、电梯状态管家三个独立模块。请求解析中心专门负责外部输入数据的合法性校验与格式转换；智能调度引擎基于电梯运行规则，采用动态规划算法生成最优路径；电梯状态管家实时维护电梯楼层、运行方向、门状态等核心状态数据，各模块通过事件驱动机制实现松耦合交互，显著提升系统扩展性。 - 分层架构优化
构建 “数据仓储层 - 业务逻辑层 - 控制协调层” 三层架构。数据仓储层使用泛型类封装乘客请求队列、电梯配置参数等数据结构；业务逻辑层将调度算法抽象为策略接口，支持 SCAN、LOOK 等多种算法的动态切换；控制协调层负责与用户终端交互，并协调各模块间的数据流，避免不同职责代码的交叉污染。
two代码规范强化 - 命名体系升级
建立语义化命名标准，避免命名随意性。类名采用 “功能 + 实体” 命名法，如ElevatorRequestProcessor；方法名采用 “动词 + 宾语” 结构，如calculateOptimalRoute；变量命名需完整表达业务含义，如用nextDestinationFloor替代简单字母变量。同时，建立命名字典文档，统一团队开发规范。 - 注释体系构建
实施三维注释策略：在类定义处添加架构注释，说明设计意图与模块边界；在方法上使用 Javadoc 格式添加接口注释，标注参数约束、返回值含义及异常处理；在复杂逻辑段添加实现注释，采用 “// 关键步骤：计算优先级权重” 的形式，配合流程图辅助理解。
three 性能优化创新 - 数据结构升级
引入 ** 跳表（Skip List）** 替代传统队列存储乘客请求，利用多层索引结构实现请求的快速插入与查询。针对 “将请求目的楼层加入内部队列” 的需求，采用哈希表与跳表结合的复合结构，在 O (1) 时间复杂度内完成请求数据的存储与检索，相比遍历队列效率提升显著。 - 计算优化策略
运用备忘录模式优化重复计算问题。在getNextFloor等频繁调用的方法中，使用ConcurrentHashMap缓存计算结果，通过楼层编号作为键值，避免重复执行相同条件判断与距离计算。同时，采用 SIMD（单指令多数据）优化技术，并行处理多个请求的方向判断逻辑。
four 逻辑重构方案 - 方法分解技巧
采用功能原子化分解，将超长方法拆解为功能单一的子方法。例如，将processRequests方法分解为parseExternalRequests（解析外部请求）、generateRoutePlan（生成路径规划）、executeElevatorActions（执行电梯动作）等多个方法，每个方法代码量控制在 30 行以内，配合单元测试保证功能独立性。 - 条件判断优化
运用状态模式重构复杂的if-else逻辑。将电梯的 “上行判断”“下行判断”“空闲判断” 等状态封装为独立类，每个状态类实现统一的determineNextAction接口，通过状态机自动切换实现电梯运行逻辑的优雅表达，有效减少嵌套层级，提升代码可维护性。
five 学习进阶建议
建议深入研究领域驱动设计（DDD）思想，将电梯调度系统划分为请求管理、路径规划、设备控制等限界上下文；同时探索响应式编程模型，利用 Java Flow API 实现请求的异步处理与非阻塞 I/O，进一步提升系统性能与稳定性。在实践过程中，定期使用 SonarQube 等代码质量分析工具进行自动化检测，持续优化代码质量。
四.总结:
one 我学会了 ：1 熟练掌握ArrayList和LinkedList在队列操作中的特性差异，能够根据场景选择合适的数据结构。例如在处理电梯请求队列时，利用LinkedList的高效插入删除特性实现动态请求管理；通过TreeMap的键值对存储机制，优化多条件请求的快速检索。
2 字符串处理与正则表达式：深度掌握substring、split等字符串函数的使用技巧，学会运用正则表达式精准解析输入数据。在电梯请求格式校验中，通过正则表达式快速识别合法楼层数据，有效提升输入处理的规范性与稳定性。
3 方法分解技巧：对于一些逻辑复杂、代码冗长的方法，如processRequests，采用功能原子化分解策略。将其拆分为多个功能单一的子方法，如parseExternalRequests专门负责解析外部请求，generateRoutePlan用于生成路径规划，executeElevatorActions执行电梯动作等。每个子方法的代码量控制在 30 行以内，确保逻辑清晰。同时，为每个子方法编写单元测试，保证拆分后的功能正确性，提高代码的可维护性与可扩展性。
4 条件判断优化：复杂的if-else逻辑嵌套不仅使代码结构混乱，还增加了出错概率。运用状态模式对其进行重构，将电梯的 “上行判断”“下行判断”“空闲判断” 等不同状态封装为独立的状态类，每个状态类实现统一的determineNextAction接口。通过状态机自动管理状态切换，当电梯状态发生变化时，自动调用相应状态类的determineNextAction方法，实现电梯运行逻辑的优雅表达，有效减少嵌套层级，提升代码的可读性与可维护性。
two 发现的不足：1 复杂场景应对不足：在面对双电梯协同调度等复杂场景时，暴露出对系统架构设计和算法优化的局限性，缺乏对多线程同步、资源竞争等问题的处理经验。
2 设计模式应用薄弱：对状态模式、策略模式等设计模式理解不够深入，导致代码中存在大量冗余的条件判断和复杂逻辑，影响代码的可扩展性和可读性。
three 对老师的建议 对于复杂作业题目，可以提供更全面的测试用例，特别是边界条件和异常场景的测试数据，帮助我们学生更快定位代码问题，提高调试效率。
浙公网安备 33010602011771号