第一次Block作业：电梯调度分析

第一次Block作业：电梯调度分析
一、前言

学习Java近两个月来，我完成了一个电梯调度系统的三次迭代开发。这个过程不仅让我对面向对象编程有了更深入的理解，更让我亲身体验了软件设计原则在实际项目中的应用价值。
第一次作业中，我设计了一个"全能"的电梯类，它承担了状态管理、请求处理、调度算法等所有职责（当然功能也没实现）。但代码臃肿，职责混乱，一个类的修改可能会影响多个功能。这让我深刻认识到单一职责原则的重要性。
第二次作业中，我按照类图要求将系统拆分为电梯类、乘客请求类、队列类和控制类。这次重构让我体会到职责分离带来的好处：每个类专注于特定功能，代码可读性和可维护性显著提升。同时，我学会了如何处理异常输入，如无效楼层和重复请求。
第三次作业最具挑战性，我引入了乘客类，改变了请求的输入方式，并实现了内外请求的联动处理。这次迭代让我理解了对象间协作的重要性，以及如何设计清晰的接口来降低耦合度。
通过这三次迭代，我不仅掌握了Java语法，更重要的是学会了如何设计可扩展、易维护的软件架构。每一次重构都是对前期设计的反思和改进，这种渐进式的学习方式让我对面向对象设计原则有了更直观和深刻的理解。
在接下来的内容中，我将详细展示三次迭代的设计思路、关键代码实现以及学习过程中的心得体会。

二、设计与分析

1.第一次作业

作业要求

设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。

代码复杂度分析

Metrics Details For File 'Elevator1.java'

---

Parameter Value
========= =====
Project Directory D:\Desktop\JAVA
Project Name Elevator1.java
Checkpoint Name Baseline
File Name Elevator1.java
Lines 261
Statements 157
Percent Branch Statements 26.1
Method Call Statements 54
Percent Lines with Comments 7.7
Classes and Interfaces 4
Methods per Class 4.25
Average Statements per Method 8.29
Line Number of Most Complex Method 28
Name of Most Complex Method Elevator.addRequest()
Maximum Complexity 13
Line Number of Deepest Block 36
Maximum Block Depth 4
Average Block Depth 1.64
Average Complexity 4.20

---

Most Complex Methods in 3 Class(es): Complexity, Statements, Max Depth, Calls

Elevator.addRequest() 13, 25, 4, 9
Elevator.Elevator() 1, 2, 2, 0
Elevator.processAllRequests() 3, 9, 3, 7
Main.main() 3, 11, 3, 7
OuterReq.OuterReq() 1, 2, 3, 0

---

Block Depth Statements

0 23
1 56
2 46
3 19
4 13
5 0
6 0
7 0
8 0
9+ 0

---

类图

踩坑心得
我的第一次的代码其实根本不对，完全没有实现题目的要求，但是我当时有认真去写了好几天，写出来的这份代码实际上就是我对于电梯运行的所有理解，并且题目中给出的测试用例，和我自己给出的测试用例都能完美通过，但是就是不知道出题老师给的唯一的那个诡异的测试点究竟是什么一直卡我答案错误，由于老师在课上有提到过会查重，所以我也不大敢直接套用已经做出来的同学的，在网上搜没想到搜到学长的代码了（这也是我后来最后悔的，被查到了领黄牌了呜呜呜），不过我还是觉得老师对于题目给的测试点太少，描述也不清晰（这个不改很多时候敲代码只会一错再错，就像我呜呜呜），这里还是继续分析下我的代码逻辑吧，具体错误的踩坑心得这点在第二次作业我会详实报告

代码逻辑解析

这个电梯调度系统采用了基于队列的请求处理机制。系统核心由Elevator类构成，包含两个主要队列：outerQueue用于存储外部请求（楼层和方向），innerQueue用于存储内部目标楼层请求。
代码的执行流程始于Main类，通过用户输入获取电梯的运行范围（最小和最大楼层），然后不断读取请求直到输入"end"命令。请求分为两种格式：外部请求<楼层,方向>和内部请求<楼层>。
processAllRequests()方法是调度核心，它首先尝试将外部请求和内部请求进行配对处理，确保每个外部请求对应一个内部请求。对于每对请求，系统采用"先外后内"的处理策略：先前往外部请求楼层，接上乘客后再前往其内部目标楼层。
在配对处理完成后，剩余未配对的请求采用传统的扫描算法处理：电梯始终保持当前运行方向，直到该方向上没有更多请求时才改变方向。系统通过determineDirection()方法决策运行方向，通过findNextTarget()寻找下一个目标楼层。（而目标楼层的定义实际上就是当前运行方向的最远内部请求楼层）

代码缺陷分析

这个实现存在几个关键缺陷，最严重的是完全偏离了题目要求。题目期望的是能够处理单个包含内外请求的完整乘客流程，但当前代码将内外请求割裂处理，破坏了乘客乘梯的完整性。
调度算法存在效率问题。processOuterThenInner()方法中的配对处理逻辑导致电梯频繁改变方向，可能在高层接上乘客后又要前往低层，产生大量的无效运行。moveToTargetWithDirectionPriority()方法虽然尝试优化，但整体路径规划仍然不够智能。
代码的可维护性较差。Elevator类承担了过多职责，既负责请求解析，又处理调度逻辑，还包含输出功能。这种高度耦合的设计使得后续修改和功能扩展变得困难。特别是将输入输出逻辑与核心调度逻辑混杂在一起，违反了单一职责原则。
错误处理机制不够健全。虽然对请求格式进行了基本验证，但对于更复杂的异常情况（如重复请求、无效楼层等）缺乏充分处理。系统没有考虑电梯容量限制、超时等实际运行中可能遇到的问题。
此外，代码缺乏足够的注释和文档，一些关键算法（如方向决策逻辑）的意图不够清晰，增加了理解和维护的难度。整体来看，这个实现虽然功能上能够运行，但在架构设计和算法效率方面都有明显的改进空间。

不必多言，直接上第二次作业吧......（拿着黄牌默默流泪）

2.第二次作业

作业要求

请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类。
电梯运行规则与前阶段单类设计相同，但要处理如下情况：
乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>

代码复杂度分析

Metrics Details For File 'Elevator2.java'

---

Parameter Value
========= =====
Project Directory D:\Desktop\JAVA
Project Name
Checkpoint Name Baseline
File Name Elevator2.java
Lines 302
Statements 240
Percent Branch Statements 21.3
Method Call Statements 118
Percent Lines with Comments 5.6
Classes and Interfaces 6
Methods per Class 5.33
Average Statements per Method 6.84
Line Number of Most Complex Method 255
Name of Most Complex Method Main.parseAndFilter()
Maximum Complexity 9
Line Number of Deepest Block 248
Maximum Block Depth 4
Average Block Depth 1.58
Average Complexity 2.52

---

Most Complex Methods in 5 Class(es): Complexity, Statements, Max Depth, Calls

Elevator.closeDoor() 1, 1, 2, 1
Elevator.Elevator() 1, 4, 2, 0
Elevator.getCurrentDirection() 1, 1, 2, 0
Elevator.getCurrentFloor() 1, 1, 2, 0
Elevator.isFloorValid() 2, 1, 2, 0
Elevator.moveOneFloor() 5, 5, 2, 1
Elevator.openDoor() 1, 1, 2, 1
Elevator.setCurrentDirection() 1, 1, 2, 0
ElevatorController.determineInitialDirection() 8, 17, 3, 11
ElevatorController.ElevatorController() 1, 2, 2, 0
ElevatorController.processAllRequests() 2, 4, 2, 4
ElevatorController.processCurrentDirection() 4, 10, 3, 8
ExternalRequest.equals() 5, 6, 2, 2
ExternalRequest.ExternalRequest() 1, 2, 2, 0
ExternalRequest.getDirection() 1, 1, 2, 0
ExternalRequest.getFloor() 1, 1, 2, 0
ExternalRequest.hashCode() 1, 1, 2, 1
Main.main() 4, 12, 4, 13
Main.parseAndFilter() 9, 26, 4, 10
RequestQueue.getInstance() 2, 3, 2, 0
RequestQueue.RequestQueue() 1, 0, 0, 0

---

Block Depth Statements

0 25
1 89
2 94
3 27
4 5
5 0
6 0
7 0
8 0
9+ 0

---

类图

踩坑心得

吸取了上次的经验，这次我对代码进行了从头到尾的重构，同时也详细咨询的各个做出了上次作业的人的代码逻辑，也有去理解做出来的学长的电梯逻辑，首先必须指出第一次作业错误的地方，首先就是第一次作业逻辑完全错误，出题老师的逻辑是每次从外部请求和内部请求两边分别取表头去进行比较判断，而我是对两边队列进行全局统筹规划，只考虑了方向优先，顺路优先，但是没考虑要串行处理（我错的这点老师似乎当时有说，但是当时教室太吵没咋听清），这点在这次分类处理之后就显得很清晰了；按照这个逻辑重构之后（具体逻辑在下面的逻辑分析我会提到），过了第一个测试点却死活第二个测试点答案错误（还是那个问题，测试点要求不清晰），在我肯定我的逻辑不会出错后，我转眼去分析了新加的要求，原来是我傻了在处理重复请求时，是直接删掉了所有重复的部分，而题目要求是只有连续出现的重复请求才删除，而这导致了我会一直多删要求楼层

代码逻辑解析

电梯在运行过程中采用基于队列头部的目标导向策略。系统始终关注两个请求队列的头部元素：外部请求队列的头部和内部请求队列的头部。电梯的移动决策完全依赖于这两个头部请求的位置关系。
当电梯处于运行状态时，processCurrentDirection方法控制着楼层的逐个判断。电梯每到达一个楼层，首先检查当前楼层是否有需要处理的请求。对于外部请求，系统要求严格的同方向匹配——只有与电梯当前运行方向一致的外部请求才会被处理。对于内部请求，只要楼层匹配即可处理，不考虑方向性。
shouldContinueCurrentDirection方法负责判断是否继续当前方向。判断依据是检查两个队列的头部请求是否仍在电梯当前运行方向的前方。如果外部请求队列头部（方向要相同）或内部请求队列头部有一个请求位于当前楼层的前方，电梯就继续前进。

电梯的方向切换通过三个关键方法实现：determineNextDirection、switchDirection和processCurrentDirection中的循环控制。方向切换发生在两种情况下：一种是处理完当前楼层请求后立即判断，另一种是完成当前方向所有请求后的强制切换。
determineNextDirection方法在处理完楼层请求后立即执行，它采用复杂的条件判断逻辑。首先检查是否存在"反向优先"情况——即外部请求和内部请求的头部都在当前运行方向的反方向。如果检测到这种模式，电梯会立即切换方向。否则，系统优先按照内部请求队列的头部决定方向，内部队列为空时才考虑外部请求。
switchDirection方法在电梯完成当前方向所有请求后触发。这个方法相对简单，主要依据内部请求队列的头部位置决定新方向。如果内部队列为空，则 fallback 到外部请求队列的头部。

代码缺陷分析

方向决策逻辑过于复杂且容易出错。determineNextDirection方法中的条件判断嵌套较深，特别是处理外部和内部请求混合的场景时，逻辑路径难以追踪。switchDirection方法的部分逻辑determineNextDirection重复，存在代码冗余。
代码可维护性较差。ElevatorController类承担了过多职责，方法之间的耦合度较高。部分算法逻辑没有充分注释，使得代码难以理解和修改。整体来看，这个实现虽然结构上比之前版本有所改进，但在核心算法和架构设计上仍有明显缺陷。

3.第三次作业

作业要求

对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类。
电梯运行规则与前阶段相同，但有如下变动情况：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）

代码复杂度分析

Metrics Details For File 'Elevator3.java'

---

Parameter Value
========= =====
Project Directory D:\Desktop\JAVA
Project Name
Checkpoint Name Baseline
File Name Elevator3.java
Lines 429
Statements 247
Percent Branch Statements 23.9
Method Call Statements 128
Percent Lines with Comments 6.1
Classes and Interfaces 6
Methods per Class 5.50
Average Statements per Method 6.12
Line Number of Most Complex Method 385
Name of Most Complex Method Main.parseRequest()
Maximum Complexity 12
Line Number of Deepest Block 393
Maximum Block Depth 5
Average Block Depth 1.69
Average Complexity 2.65

---

Most Complex Methods in 5 Class(es): Complexity, Statements, Max Depth, Calls

Elevator.Elevator() 1, 4, 2, 0
ElevatorController.determineInitialDirection() 8, 17, 4, 11
ElevatorController.ElevatorController() 1, 2, 2, 0
ElevatorController.processAllRequests() 2, 4, 3, 4
ElevatorController.processCurrentDirection() 4, 10, 3, 8
Main.main() 4, 12, 4, 13
Main.parseRequest() 12, 18, 5, 11
Passenger.equals() 5, 6, 2, 2
Passenger.getDestinationFloor() 1, 1, 2, 0
Passenger.getSourceFloor() 1, 1, 2, 0
Passenger.hashCode() 1, 1, 2, 1
Passenger.Passenger() 1, 2, 2, 0
RequestQueue.addExternalRequest() 3, 3, 3, 4
RequestQueue.addInternalRequest() 3, 3, 3, 4
RequestQueue.areBothQueuesEmpty() 1, 1, 2, 2
RequestQueue.getExternalHead() 2, 1, 2, 2
RequestQueue.getInstance() 2, 3, 3, 0
RequestQueue.getInternalHead() 2, 1, 2, 2
RequestQueue.hasExternalRequests() 1, 1, 2, 1
RequestQueue.hasInternalRequests() 1, 1, 2, 1
RequestQueue.removeExternalHead() 2, 3, 3, 2
RequestQueue.removeInternalHead() 2, 2, 3, 2
RequestQueue.RequestQueue() 1, 0, 0, 0

---

Block Depth Statements

0 23
1 85
2 99
3 29
4 8
5 3
6 0
7 0
8 0
9+ 0

---

类图

踩坑心得

实际上我觉得这次的题目就很简单了，逻辑和上次完全一样，只需要变动外部队列的输入，根据输入的两个楼层先去判断方向，然后摘队尾塞到内部队列即可，当然虽然说是队列实际上我觉得用链表更方便啦，所以最后两次代码我都是上的链表，不然队列又塞又删麻烦还容易出错，由于这次改完是一遍过，我就直接上逻辑分析和缺陷分析了（这里我必须提一下，我感觉出题老师是不是把第二个测试样例的输出结果设置错了，我问了很多做出来的同学，他们似乎第二个测试用例也都无法通过，而通过了第二个测试用例的却无法保证答案正确，这太诡异了）

代码逻辑分析

电梯系统的核心运行逻辑集中在ElevatorController类的processCurrentDirection方法中。电梯采用基于当前运行方向的逐层扫描策略，运行过程中始终保持当前方向直到该方向上没有更多待处理请求。
电梯每到达一个楼层，首先执行processRequestsAtCurrentFloor方法处理当前楼层的请求。对于外部请求，系统要求严格的同方向匹配条件：只有当乘客的请求方向与电梯当前方向一致时才会开门接客。处理外部请求时，系统会将乘客的目标楼层自动添加到内部请求队列，实现了乘客旅程的完整性。对于内部请求，只要楼层匹配即可处理，不考虑方向性。
方向判断逻辑通过shouldContinueCurrentDirection方法实现。该方法仅检查两个请求队列的头部元素是否位于电梯当前运行方向的前方。如果外部请求队列头部或内部请求队列头部有一个请求满足条件，电梯就继续沿当前方向运行。
方向切换机制分为两种情况。determineNextDirection方法在处理完楼层请求后立即执行，它首先检查是否存在"反向优先"的特殊情况，即两个队列头部都在当前方向的反方向。如果检测到这种模式，电梯会立即切换运行方向。否则，系统优先按照内部请求队列的头部位置决定新方向。switchDirection方法在完成当前方向所有请求后触发，采用类似的决策逻辑但更侧重于内部请求的优先级。

代码缺陷分析

方向决策逻辑过于复杂且容易出错。determineNextDirection方法中的条件判断嵌套层次过深，特别是处理外部和内部请求混合场景时，逻辑路径难以追踪和维护。代码中存在多处重复的方向判断逻辑，违反了DRY原则。
错误处理机制不完善。系统对无效请求的处理过于简单，只是静默忽略异常情况。对于并发请求处理、电梯超载、运行超时等实际场景中可能出现的问题缺乏相应的处理机制。
代码可维护性较差。ElevatorController类承担了过多的职责，方法之间的耦合度较高。部分核心算法缺乏充分的注释说明，使得代码逻辑难以理解和修改。整体来看，这个实现虽然在架构上有所改进，但在核心算法和实际应用场景适配方面仍有明显不足。

三、三次电梯调度作业的踩坑心得

第一次作业：从自信满满到当头一棒

第一次接触电梯调度问题时，我内心其实是有些轻敌的。觉得不就是让电梯上下跑嘛，能有多难？于是按照自己的理解，设计了一个"全能型"电梯类，把所有功能都塞进去。当时还暗自得意，觉得代码结构挺清晰的，测试用例也都能通过。
结果现实给了我一记重击。那个唯一的测试点就像一座大山，我怎么也翻不过去。最痛苦的是，根本不知道错在哪里。测试点描述太模糊了，我只能靠猜。那几天我反复检查代码逻辑，甚至重写了三遍，但就是过不了。
更糟糕的是，在焦虑中我犯了一个致命错误——上网搜索解决方案。当我看到学长的代码时，就像抓住了救命稻草，虽然没直接抄袭，但思路受到了很大影响。这个黄牌让我深刻认识到，学术诚信的底线绝对不能碰，再难也要自己思考。
现在回头看，最大的问题是我根本没理解题目的核心要求。我以为的"智能调度"和出题老师想的完全不是一回事。这种认知偏差导致我从一开始就走错了方向。

第二次作业：在细节中迷失方向

第二次作业我格外小心，完全按照类图要求进行模块化设计。在咨询了多位同学后，我终于明白了第一次错在哪里——原来是要串行处理请求，而不是全局统筹。
重构过程很顺利，新代码结构清晰了很多。但第二个测试点又卡住了。这次我学乖了，先肯定自己的核心逻辑没问题，然后逐项检查新加的需求。果然发现了问题：我在处理重复请求时，把所有的重复项都删了，而题目要求只删除连续重复的。
这个细节让我意识到，读题要像做阅读理解一样仔细。每个字词都可能隐藏着关键信息。同时，调试时要有系统性思维，不能盲目修改。先确认核心逻辑正确，再逐个排查边界情况。

第三次作业：看似简单却暗藏玄机

第三次作业表面上看只是改个输入格式，但我不敢掉以轻心。
代码一次通过让我有些意外，但更让我困惑的是第二个测试点的问题。和其他同学交流后发现，大家都遇到了类似情况：要么过不了测试点但逻辑正确，要么通过测试点但可能存在其他问题。
这种集体性的困惑让我意识到，有时候问题可能不在我们身上。但作为学生，我们还是要从自身找原因，把基础打扎实才是根本。

四、总结

最初接触电梯调度问题时，注意力完全集中在如何让代码运行起来。第一个版本只追求基本功能的实现，把所有逻辑都塞进一个类里，认为只要能处理请求、电梯能移动就完成了任务。这种思路导致代码变成了一个庞大的单体结构，虽然能运行，但修改任何功能都可能引发连锁问题。
随着开发的深入，逐渐认识到架构设计的重要性。第二个版本尝试进行模块拆分，将请求管理、电梯控制、调度逻辑分离。这个过程让我体会到，好的代码不仅仅是能运行，还要易于理解和修改。单例模式的使用虽然不完美，但让我第一次接触到设计模式的实际应用，开始思考如何通过架构设计来提高代码的可维护性。
第三个版本的Passenger类设计是一个重要的转折点。它让我意识到，编程不仅仅是实现功能，更重要的是建立正确的领域模型。将乘客请求作为一个完整的业务实体来处理，比简单拆分内外请求更符合现实逻辑。这种从过程式思维向面向对象思维的转变，是这次开发过程中最宝贵的收获。