南昌航空大学-软件学院-余思莹-第一次blog作业

目录

• 一、前言
• 二、设计与分析
  • 2.1 OOP1-NCHU_单部电梯调度程序
    • 2.1.1 题目
    • 2.1.2 设计与分析
  • 2.2 OOP2-NCHU_单部电梯调度程序
    • 2.2.1 题目
    • 2.2.2 设计与分析
  • 2.3 OOP3-NCHU_单部电梯调度程序
    • 2.3.1 题目
    • 2.3.2 设计与分析
• 三、踩坑心得
• 四、改进与分析
• 五、总结

一、前言

这三周Java大作业给我最大的感受就是类图很重要，画好了类图再来写程序整体思路会清晰很多，特别是问题越来越复杂的情况，在做题目的时候最好都应该先思考，画类图，再编程。
- 第一次题目集
第一次题目包含五道题目，前四道小题都是考察的知识点主要都是正则表达式，同时涉及到循环、条件判断等一些基础编程知识。最后一道大题要求模拟电梯运行逻辑完成程序设计，核心在于状态管理、请求队列管理以及调度算法的设计。总体来说，题量中等，前四道题目难度较低，最后一道电梯调度程序设计难度较大。

- 第二次题目集
第二次题目包含三道题目，前两道题目重点在场景下给出问题，要求分多个类进行设计，帮助我们从之前面向过程设计的思想转换到面向对象编程。最后一道电梯调度程序设计是在第一次的电梯调度程序设计基础上迭代，同样地，考察的内容之一是多个类的设计，只需要将第一次代码转换为更多个可复用的类，另一方面需要添加对输入时出现连续的相同请求的处理。第二次题目集基本上都给出了参考类图，参考完成即可，这次的电梯调度程序设计题也只是添加一个自动忽略相同的多余输入的小功能，有了前一次的基础做起来相对好点，总体来说题量一般，难度中等。

- 第三次题目集
第三次题目包含三道题目，前两道题依然聚焦一些场景，总体根据题目类图提示完成类的设计即可，这两道题的难度主要在实现核心功能的方法的设计，需要我们厘清题目中的具体规则。第三道题依然是电梯调度程序设计，要求在之前的基础上修改类的设计，同时输入也发生了变化，对于输入的处理也发生了变化，这道题也是我碰到最多问题的一道题，后续娓娓道来。此次题目集题量一般，难度很大。

---

- 关于SourceMonitor的使用
第一次使用SourceMonitor进行代码度量，对这个软件还不是很熟悉，下面这篇博客详细讲述了如何使用Source Monitor测量Java代码的圈（环）复杂度，可以作为一个很好的参考https://zhuanlan.zhihu.com/p/41635295
第一次使用这个软件也碰到了一些小问题，这里简单总结下两个注意事项

1. 不要在IDE和SourceMonitor同时打开代码文件，否则你的度量结果将会是 ↓
   
2. 新建project时需要选择或填写两个路径，注意第一个填的是分析文件的保存路径，第二个才是代码源文件路径，这个有点反人类了 一般不都是先填源文件吗，一不注意看就填错了

二、设计与分析

2.1 OOP1-NCHU_单部电梯调度程序

2.1.1 题目

7-5 NCHU_单部电梯调度程序
分数 70
作者 段喜龙
单位 南昌航空大学
设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例:
在这里给出一组输入。例如：

1
20
<3,UP>
<5>
<6,DOWN>
<7>
<3>
end

输出样例:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door

以下是一些约束条件

代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB

2.1.2 设计与分析

整体类图设计

设计总结

1. 类与职责

• ExternalRequests 类：用于存储外部请求，将目标楼层和方向这两个属性封装，提供了getter方法以供外部代码访问这些属性。
• Elevator 类：用于管理电梯的全部运行逻辑。它维护了电梯的关键状态，包括当前楼层、运行方向以及楼层的上下限。提供了相应的setter与getter方法。
• Main 类：该类作为整个应用程序的入口点，主要负责流程的控制和用户交互。

2. 数据结构使用
   使用ArrayList存储内部请求和外部请求，方便动态添加和删除请求，符合请求数量不确定的实际场景。
3. 交互设计
   通过控制台输入获取电梯运行相关请求信息，输入格式通过正则表达式进行校验，保证输入数据的格式正确性。当输入"end"（不区分大小写）时停止接收请求并开始处理已有的请求。

SourceMonitor度量结果

分析总结

1. 方法复杂度
   代码中Elevator.determineDirection()方法复杂度较高（19, 21, 5, 26 ），圈复杂度达到了19，Elevator.handleOuterStop()也相对较复杂，圈复杂度为10，这两个方法中都集成了许多功能，并且包含许多分支。
2. 运行逻辑
   采用 “先来先服务” 策略，按请求添加顺序处理，未考虑电梯当前方向与请求的匹配度（如电梯向上运行时，下方的请求需等待电梯返回后处理）。如电梯从 1 楼向上到 5 楼，中途无请求时处理起来可能出现问题。
3. 可扩展性
   输入方式可扩展，Main 类的输入逻辑可抽离为独立方法，可降低复杂度。

2.2 OOP2-NCHU_单部电梯调度程序

2.2.1 题目

7-3 NCHU_单部电梯调度程序（类设计）
分数 50
作者 段喜龙
单位 南昌航空大学
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。
电梯迭代1类图.png
电梯运行规则与前阶段单类设计相同，但要处理如下情况：

乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>
注意：本次作业类设计必须符合如上要求（包含但不限于乘客请求类、电梯类、请求队列类及控制类，其中控制类专门负责电梯调度过程），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次电梯程序提交到本次题目中测试）。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：

1
20
<3,UP>
<5>
<6,DOWN>
<7>
<3>
end

输出样例1:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door

输入样例2:
在这里给出一组输入。例如：

1
20
<3,UP>
<3,UP>
<5>
<5>
<5>
<6,DOWN>
<7>
<7>
<3>
<22,DOWN>
<5,DOWN>
<30>
END

输出样例2:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Open Door # Floor 3
Close Door
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Open Door # Floor 6
Close Door
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door

以下是一些约束条件

代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB

2.2.2 设计与分析

整体类图设计

设计总结

1. 类与职责

• Main 类：用于读取用户输入，通过正则表达式验证和解析请求，然后将请求添加到RequestQueue中。作为整个应用程序的入口点，主要负责流程的控制和用户交互。
• Controller 类：电梯系统调度核心控制逻辑，用于接收来自RequestQueue的请求找到下一个下一个方向，统一协调了请求处理、方向决策和电梯状态变更。
• Elevator 类：用于维护自身的状态，并提供修改和查询这些状态的方法。
• RequestQueue 类：用于管理所有待处理的请求，提供了添加内部和外部请求的方法，并在添加时实现了简单的去重逻辑（第二次迭代相对于第一次的主要变化就在这，代码也在此修改)。

点这里看修改前代码

// 增加内部请求public void addInternalRequest(int floor) {internalRequests.offer(floor);}
// 增加外部请求public void addExternalRequest(int floor, Direction direction) {externalRequests.offer(new ExternalRequest(floor, direction));}

点这里看修改后代码

    // 增加内部请求，在这里添加去重逻辑public void addInternalRequest(int floor) {// 若队列不为空，且最后一个请求与当前请求相同，则忽略if (!internalRequests.isEmpty() && internalRequests.getLast() == floor) {return;}internalRequests.offer(floor);}// 增加外部请求，在这里添加去重逻辑public void addExternalRequest(int floor, Direction direction) {ExternalRequest newRequest = new ExternalRequest(floor, direction);// 若队列不为空，且最后一个请求的楼层和方向都与当前相同，则忽略if (!externalRequests.isEmpty()) {ExternalRequest lastRequest = externalRequests.getLast();//还未把新元素加入队列前，队列的最新元素if (lastRequest.getFloor().equals(floor) && lastRequest.getDirection() == direction) {return;}}externalRequests.offer(newRequest);}

• ExternalRequest 类：用于将一个外部请求所需的所有信息打包成一个对象。
• Direction/State 枚举：用于存储电梯运行方向和状态信息。

2. 数据结构使用
   在RequestQueue中使用LinkedList来存储内部和外部请求。电梯处理请求主要是add（尾部添加）和removeFirst（头部移除），LinkedList在这些操作上更具优势。
3. 交互设计
   Main类负责所有输入输出。它首先读取最小和最大楼层，然后进入循环读取请求。使用正则表达式来验证输入格式，输入 “end” 输入结束，触发电梯开始处理请求。
   move方法内部实现了电梯移动的完整过程：更新楼层 → 输出状态 → 判断是否停层 → 开关门 → 决策下一个方向。

SourceMonitor度量结果

分析总结

1. 方法复杂度
   本次代码中依然是Elevator.determineDirection()方法复杂度较高（19, 25, 5, 18 ），圈复杂度达到了19，Elevator.handleOuterStop()也相对较复杂，圈复杂度为10，这两个方法中都集成了许多功能，并且包含许多分支。另外本次代码相比前一次主要是在RequestQueue类中的方法操作，因此RequestQueue类中的方法复杂度也略有上幅。
2. 运行逻辑
   仍采用“先来先服务 + 同向优先”的调度策略，核心逻辑封装在Controller类。processRequests()作为主循环驱动电梯运行，每次循环中move()方法负责更新楼层并输出状态，shouldStop()判断是否停层并调用对应方法处理请求、移除已完成项，最后determineDirection()根据剩余请求和当前方向决策下一轮运行方向，减少无效折返。整体逻辑能满足基本运行需求，但处理同向非队首请求时效率有待优化。
3. 可扩展性
   Main类负责交互，Controller类处理调度，Elevator类维护状态，RequestQueue和ExternalRequest类管理请求。这种设计让各模块相对独立，后续替换调度算法只需修改Controller类，扩展请求属性可直接在ExternalRequest类中添加。

2.3 OOP3-NCHU_单部电梯调度程序

2.3.1 题目

7-3 NCHU_单部电梯调度程序（类设计-迭代）
分数 50
作者 段喜龙
单位 南昌航空大学
对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。
类图.png
电梯运行规则与前阶段相同，但有如下变动情况：

乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
注意：本次作业类设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次及第二次电梯程序提交到本次题目中测试）。

输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<请求源楼层，请求目的楼层>，其中，请求源楼层表示乘客发起请求所在的楼层，请求目的楼层表示乘客想要到达的楼层。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
输入样例1:
在这里给出一组输入。例如：

1
20
<5,4>
<5>
<7>
end

输出样例1:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Open Door # Floor 7
Close Door
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Open Door # Floor 5
Close Door
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door

输入样例2:
在这里给出一组输入。例如：

1
20
<5,9>
<8>
<9,3>
<4>
<2>
end

输出样例2:
在这里给出相应的输出。例如：

Current Floor: 1 Direction: UP
Current Floor: 2 Direction: UP
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Open Door # Floor 5
Close Door
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Open Door # Floor 8
Close Door
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Open Door # Floor 4
Close Door
Current Floor: 3 Direction: DOWN
Current Floor: 2 Direction: DOWN
Open Door # Floor 2
Close Door
Current Floor: 3 Direction: UP
Current Floor: 4 Direction: UP
Current Floor: 5 Direction: UP
Current Floor: 6 Direction: UP
Current Floor: 7 Direction: UP
Current Floor: 8 Direction: UP
Current Floor: 9 Direction: UP
Open Door # Floor 9
Close Door
Current Floor: 8 Direction: DOWN
Current Floor: 7 Direction: DOWN
Current Floor: 6 Direction: DOWN
Current Floor: 5 Direction: DOWN
Current Floor: 4 Direction: DOWN
Current Floor: 3 Direction: DOWN
Open Door # Floor 3
Close Door

以下是一些约束条件

代码长度限制
16 KB
时间限制
400 ms
内存限制
64 MB
栈限制
8192 KB

2.3.2 设计与分析

整体类图设计

设计总结

1. 类与职责

• Main 类：作为程序入口，负责读取用户输入。
• Controller 类：依然是电梯系统的调度核心。它根据 RequestQueue 中的请求和 Elevator 的当前状态，从内部和外部请求队列中选择最优的下一个目标。当电梯到达一个目标楼层时，Controller 会负责将该外部请求的目的楼层转移到内部请求队列中。
• Elevator 类：负责维护电梯自身的状态，包括当前楼层（currentFloor）、运行方向（direction）以及楼层上下限。它提供 getter 和 setter 方法供 Controller 查询和修改状态。
• RequestQueue 类：负责管理所有待处理的请求。与上一版不同，它现在内部维护两个队列：一个LinkedList用于存储内部请求的目的楼层；另一个 LinkedList用于存储外部请求的乘客对象。它提供了添加这两种请求的方法。
• Passenger 类：这是本次迭代新增的核心类，用于封装一个乘客的完整行程信息。对于外部请求的乘客，它包含了 sourceFloor（源楼层）、destinationFloor（目的楼层）和 direction（乘梯方向，由源楼层和目的楼层计算得出）。对于内部请求的乘客，它可以只包含 destinationFloor。
• Direction 枚举：定义了电梯的运行方向（UP, DOWN, IDLE），也用于表示乘客的乘梯方向。

2. 数据结构使用
   RequestQueue 内部继续使用 LinkedList 来分别存储内部请求和外部请求。
   LinkedList 在处理队列头部的删除操作时效率很高，这非常适合 “先进先出” 的调度模型。
   新增的 Passenger 类作为一个数据载体，将乘客的源、目的楼层和方向捆绑在一起，使得 RequestQueue 中对外部请求的管理更加直观和封装化。
3. 交互设计
   输入处理：Main 类需要解析两种新的输入格式。对于外部请求 <源楼层,目的楼层>，它会创建一个 Passenger 对象，并计算出其 direction。
   核心逻辑交互：Controller 的 processRequests() 方法驱动电梯运行。它通过 getNextFloor() 确定下一个目标楼层，然后控制电梯移动到该楼层。
   请求转换：当电梯到达一个外部请求的源楼层并开门后，Controller 会从外部请求队列中移除该 Passenger 对象，并将其 destinationFloor 添加到内部请求队列的末尾。这是本次迭代最核心的业务逻辑变化，模拟了乘客进入电梯后按下目的楼层按钮的行为。
   输出：电梯移动和开关门的输出逻辑与前两个版本类似，由 Controller 控制。

SourceMonitor度量结果

分析总结

1. 方法复杂度
   复杂度最高的方法集中在 Controller 类。getNextFloor() 方法的复杂度最高，达到了16，这是因为它集成了所有核心的调度决策逻辑。该方法需要遍历内部和外部请求队列，评估每个请求与当前电梯状态的关系（是否同向、距离远近等），然后做出最优选择。多重的 if-else 判断和循环导致了较高的圈复杂度。
   Controller.processRequests() 方法的复杂度也较高，为10。它不仅包含了驱动电梯移动的主循环，还集成了处理请求队列转换和开关门的逻辑，职责相对较重。
   Main.main() 方法的复杂度（CCN=9）主要来源于新增的输入格式解析逻辑，需要区分和处理内部、外部两种请求。
2. 运行逻辑
   本次迭代的运行逻辑在 “先来先服务” 和 “同向优先” 的基础上，增加了 “请求转换” 的机制。当一个外部乘客被电梯接载后，其目的地会成为一个新的内部请求，题目中给出了详细解释。
   Controller.getNextFloor() 方法是逻辑核心。它需要综合考虑当前电梯方向、内部请求队列中是否有同向的请求、外部请求队列中是否有同向且在当前楼层前方的请求以及在没有同向请求时，如何选择反向的请求。
3. 可扩展性
   Passenger 类的存在极大地增强了系统的可扩展性，以后用户信息需要改变或增加是只需复用或修改该类的内容，同时核心调度算法仍然封装在Controller类中，后续优化调度策略时只需重写该类中的 getNextFloor() 方法。

三、踩坑心得

• 思考方式的固化与对题意理解不到位
  现在回过头来看，一开始拿到题目，第一个思考方向就是面向过程的方式，也没有太仔细研究电梯的运行方式，有点按照现实生活的电梯运行方式，试图在Main类里甚至是Main函数里解决问题，但是确实比较复杂，思考无果。后面上课的时候老师讲了这次大作业的内容，电梯运行逻辑和现实中不同，（其实这里我当时也想了好一会，为什么电梯里面会有人不分时段的按电梯？）通过秋游的例子我也更加深刻体会到了面向对象编程的好处，在Java程序设计时思考方式慢慢转变
• end不区分大小写，DOWN和UP要求大写
  想到之前刚好学习了正则表达式的使用，这一块我也就也想用正则表达式完成，但其实也不是所有成绩都适合正则表达式。比如这里对于end的输入，只需s.equalsIgnoreCase("end")就可以了，用正则表达式反而显得累赘了。但UP和DOWN还是可以用正则表达式，毕竟它们是归属于某一组输入的，用正则表达式匹配或提取都更方便。
• 运行超时怎么办
  在三次电梯调度程序中都碰到了许多次运行超时的情况，其中一次是因为一开始想要每到一层楼就判断一次是否要开门，开门的则输出开关门信息，不开门则只输出楼层信息，可能是分支语句或是输出语句写多了？导致一直运行超时，最后修改为先找到下一次的楼层，再在此层停靠，问题解决
  
  第三次电梯程序也有这个问题，在同学帮助下发现和空指针相关，修复代码中可能出现的空指针边界情况即可
  

四、改进与分析

通过对三次电梯调度程序的迭代开发和 SourceMonitor 的复杂度分析，我认识到代码质量和可维护性的重要性，一段好的程序经得起推敲，体现在大作业中就是复杂度相对较低，且每次迭代起来方便。以下是我对这三次作业的改进设计：
降低方法复杂度，提升可读性与可测试性

1. 三次迭代中，Controller 类的核心方法，即实现找到下一楼层的方法始终是复杂度最高的部分。这导致代码逻辑密集，难以理解和调试。可以对此方法进行逻辑拆分，进行重构，将其内部的子逻辑拆分成多个私有辅助方法。
2. 查阅资料发现，对于调度算法本身，可以考虑使用策略模式，这个在后续学习中会涉及到。即定义一个 ElevatorStrategy 接口，其中包含 getNextFloor() 方法。然后为不同的调度策略创建具体的实现类。
3. 强化类的职责单一性，优化类间交互。Controller 类在承担调度决策职责的同时，还负责了大量的队列操作和状态转换逻辑（如将外部请求的目的楼层加入内部队列），职责不够纯粹，此处可做改进。
4. 优化输入处理与代码健壮性。Main 类的 main 方法承担了输入读取、解析、验证等所有职责，导致其复杂度也偏高，可以将输入、正则表达式解析验证等各自创建为一个单独的类。

五、总结

这是学习JAVA以来的第一次Blog作业，早在学习Java之前，就有听之前的学长学姐说过面向对象程序设计这门课的的学习方式和之前有很大不同，现在看来确实是这样，线上加线下的学习方式更加考验我们的自学能力与对知识的熟练掌握程度。
通过三周的大作业和每三周一次的Blog，阶段性的复盘总结，加之老师上课生动的讲解感觉知识以一种神奇的方式进入了脑子，自己的编程水平也确实有在提升。
这三周学习到的知识主要有正则表达式的使用、类的设计及职责划分以及类图的重要性，主要还是一些基本的利用Java知识进行编程的知识，另外一个就是从从前的面向过程到现在的面向对象编程思想的转变。同时对于类结构的设计是一个一直需要研究下去的内容，对每个类内部方法的优化也是如此，像这样每次迭代的大作业，如果第一次的类结构设计的好的话，后续迭代起来也会方便许多。
最后给出题老师一些小建议，希望能不断优化测试样例和题目的匹配，第三次迭代时两个测试样例全通过和全没通过的同学都通过了所有测试点，一时不知道代码应该往哪个方向修改了...