BLOG1-NCHU-单部电梯调度程序

news/2025/11/22 15:54:16/文章来源:https://www.cnblogs.com/NCHUhzf23207224/p/19253997

题目集 1-3 单部电梯调度程序

一.前言

历经三周的时间，也是完成了每周一次Java课程的大作业。在我们每次完成的大作业当中均包含着NCHU-单部电梯调度程序的相关题目，并且每周题目呈现迭代递进的特点。从题目集1的NCHU_单部电梯调度程序到题目集2的NCHU_单部电梯调度程序（类设计）最后到题目集3的NCHU_单部电梯调度程序（类设计-迭代）。一环套一环，设计要求越来越多，逐步变的有挑战性。但同时也在引导着我们在面对一个项目时应该怎么去解决问题，而不是上手就直接敲代码，应该深入理解面向对象编程。
在这三次题目集中，我认为主要涉及到的知识点有：1.单一职责原则（SRP）从题目集1的单部电梯类，到题目集2中拆分出的电梯类、乘客请求类、队列类、控制类，最后再到题目集3替换为电梯类、乘客类、队列类和控制类，每个类承担单一职责。2.类的封装和职责划分，随着题目集的不断迭代，可以通过不同类，降低模块间的耦合。3.队列的应用，不管是乘客在内部或者在外部，统一是采用队列的方式来实现电梯调度的问题。切在乘客进入队列的过程中保持的是先进先出（FIFO）的特性。4.电梯运行的算法问题，在解决这三次的题目中我认为最主要的还是算法问题，只要把电梯运行的算法问题搞懂了，剩下的问题就相对于比较简单也就能够迎刃而解。

二.设计与分析

题目集1：NCHU_单部电梯调度程序

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

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

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

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door

SourceMonitor分析

类图分析

分析与心得
在完成这道题过程中，经历了许多的小问题在那段时间也时常为这些小问题思考着该如何解决。以下是我从截取有用信息，算法设计以及代码质量方面的分析。
一.截取有用信息
在初次处理输入数据时，我首先想到的是通过String方法来比对输入是否正确，并且从中提取有用信息，比如乘客是从外部进入电梯还是从内部出电梯等情况分析，但我发现这种情况不利于分析，需要用到大量的if-else语句才能实现以上功能，这无疑加重了代码的质量而且也十分容易出错。恰好在大作业发布前，老师跟我们讲了正则表达式，于是我便尝试用正则表达式来解决上面的问题，不仅方便而且也让代码看起来十分简洁。
使用逻辑如下：

直接通过正则表达式，分别判断内部和外部
然后将内部或者外部信息加入创建好的两个队列中去
最后通过算法的设计，解决电梯开关输入出的问题。

二.算法设计
我认为不管是在题目集1中亦或者是在题目集2,3中最难的点就是算法分析这块。因为你得了解电梯是如何进行调度的才能实现代码的正确性。起初我就是因为算法的问题一直想错从而导致在前期一直出现报错的问题。比如在判断电梯运行下一个楼层的方向，起初我是以电梯的运行方向判断，也就是在运行过程中这一方向运行完之后再往反方向运行。这种想法肯定是错误的，因此我就在考虑电梯的下一个楼层的运行方向到底是往哪边的，由什么因素决定的。
在经过反复的思考以及老师发布的关于本题测试样例的分析。经过不断的调试和修改，我将电梯下一个运行方向的所有结果都列出来了，最终也是通过了所有的测试点。以下我就来分析关于我对电梯下一个运行方向的部分情况：（剩余情况按照以上判断一样）

以上是我对电梯运行方向的部分判断。电梯下一个楼层的运行方向不仅与方向有关而且还与楼层之间的距离有关！这是解决该问题的重点！
三.代码质量的深度分析
通过 SourceMonitor 生成的代码分析报告，可以清晰地看出我提交的代码虽然通过了测试点，但在质量上存在不少问题：

类数量方面：在该文件中，我只分了3个类，类拆分不足，可能存在职责耦合的情况。可在后续的代码中多增加几个类，存在优化空间。
AvgStmts/Method：每个方法的平均语句数（7.00），语句数过多的方法可能逻辑过于臃肿，需考虑拆分。
嵌套深度：当前我的最大嵌套深度达到了5，存在嵌套过深的现象，会降低可读性，可通过提前return减少。
这次大作业让我收获最多的就是，当面对一个题目其中要求较多的情况下，应当如何正确的进行分析应该做些什么。

题目集2：NCHU_单部电梯调度程序（类设计）

题目如下：
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段单类设计相同，但要处理如下情况：

乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>

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

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
注意：本次作业类设计必须符合如上要求（包含但不限于乘客请求类、电梯类、请求队列类及控制类，其中控制类专门负责电梯调度过程），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次电梯程序提交到本次题目中测试）。

SourceMonitor分析

类图分析

分析与心得
此次题目相对于上次在算法方面没有什么改变的，但是在类的设计方面有所提升，从原来的三个类变成了六个类，实现了对类的扩展。
一.数据结构方面
在该题目中要求 “过滤连续相同请求”，我曾错误地用HashSet对整个队列去重，导致 “非连续的相同请求也被过滤”（如<3> <4> <3>被误判为重复）。正确做法是仅过滤 “连续相同” 的请求，通过记录 “最后一个入队的请求” 来实现去重，保证队列的 FIFO 特性不受破坏。
二.算法方面
功能实现中的问题与解决：在实现去重功能时，需要考虑的一点是怎么判断该数据是否重复以及怎样去除。当时在思考这个题目时，我就存在过是否是将数据中存在的所有重复数据给去除还是只去除临近的数据的问题，不过最终通过我不断的测试找出了错误的方向并把它纠正。
三.代码方面
通过SourceMonitor分析，可以看出% Branches=18.9%（分支语句占比），分支占比适中，说明核心调度逻辑（如方向决策、停靠判断）的条件判断既覆盖了业务规则的复杂性，又未过度冗余，相比题目集 1 的 27.4% 有明显优化。Avg Complexity=1.00（平均方法复杂度）：多数方法是简单逻辑（如 getter、setter、工具方法），只有少数核心方法（如Controller的调度算法）承担复杂逻辑，符合 “复杂逻辑集中化” 的设计原则。

题目集3：NCHU_单部电梯调度程序（类设计-迭代）

题目如下：
对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图。

电梯运行规则与前阶段相同，但有如下变动情况：

乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）

注意：本次作业类设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次及第二次电梯程序提交到本次题目中测试）。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。

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

运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
SourceMonitor分析

类图分析

分析与心得
这次的题目与前两次的题目电梯运行的方向算法差不多一致，但外部楼层的输入方式却有不同，从原来的<目的楼层数,运行方向>，变为了<请求源楼层，请求目的楼层>。这里就得十分注意乘客的运行方向问题。以下我也是从三个方面对此次题目进行分析，分别是信息截取方式，算法设计以及代码质量分析。
一.信息截取方式
与前两次的输入方式有所不同，外部输入方式变成了<请求源楼层，请求目的楼层>，因此相对应的正则表达式就要有所的改变，内部楼层的信息获取可以不变但对于外部的就得改变，此时就还有一个问题，外部楼层有两个电梯数，应该把那个放在外部队列里或者说两个都放在外部队列里？这是一个值得思考的问题。
二.算法设计
为什么我说对于一个题目，我认为最主要的是一个题目的算法，只有算法搞懂了那么这个题目也就完成了至少一半。这道题在发布后的至少4天里，我都把这道题的算法搞错，导致一直有个测试点没有过，就是首先当输入了外部楼层后应该先判断这个外部请求是UP还是DOWN。其次对应与当前电梯的运行方向是否相同再进行分析当前电梯运行方向
三.代码质量分析
通过 SourceMonitor 生成的代码分析报告，可以看到代码方面的质量有了部分的提升。从题目集1中的3个类变为了5个类（其中不包含枚举类），在类的设计方面有了提升。不仅如此，注释行占比达到了15.9%属于中上等的注释密度，能有效辅助理解关键逻辑。

三.踩坑心得

1.代码优化方面

随着这三次的大作业完结，关于大作业中的单部电梯调度程序的题目也正式结束。我认为在代码方面，是一步一步的精简了许多。而且逻辑思维也更加清晰了很多，从刚开始的只会使用一个最简单的main类开始到后面使用3个，5个类将代码进行精简封装。不仅如此，在控制类中，起初我将 “电梯、内部队列、外部队列” 作为方法参数频繁传递，导致方法签名冗长且耦合度高。最后通过类的成员变量封装依赖，控制类在初始化时注入电梯和队列，方法内部直接调用，简化接口并降低耦合。

2.算法方面

在电梯调度的算法上，实际上踩了不少的坑。起初设计方向决策时，仅考虑 “当前队列头的方向”，忽略了 “同方向所有请求的覆盖”。例如，当内部队列有5、外部队列有3,UP时，若电梯当前在 1 层且方向为 UP，正确逻辑是先处理内部的5，但我误判为优先处理外部的3,UP，导致调度顺序错误。解决方法是先收集所有同方向请求，再选最近目标，确保 “同向优先” 是 “同方向所有请求的优先”，而非仅队头优先。

3.数据结构方面

一开始我想到的并不是通过队列的方式来做，而是通过数组的方式，这种方式不仅容易搞混而且不易操作相对于队列。

四.改进建议

1.类设计的进一步解耦

可将 “队列的去重、校验逻辑” 从RequestQueue中拆分到独立的 “请求校验类” 中，让RequestQueue仅负责队列的存储与操作，进一步遵循单一职责原则。例如，新建RequestValidator类，专门处理 “楼层有效性校验”“连续重复过滤” 等逻辑，使RequestQueue的职责更纯粹。

2.算法的优化

这段时间老师也为我们详细讲解了java的三大类，电梯调度算法可抽象为 “策略接口”，方便后续扩展不同调度规则（如 “最短距离优先”“优先级乘客优先”）。例如，定义SchedulingStrategy接口，包含determineDirection()和getNextFloor()方法，当前的 “同向优先” 算法作为其实现类SameDirectionStrategy，若需新增策略，只需实现接口即可，无需修改核心控制逻辑。

3.代码方面的优化

关键算法（如方向决策、停靠处理）可添加更详细的 “逻辑分段注释”，用注释明确每个条件分支的意图。例如，在determineDirection方法中，对 “双队列非空”“仅内部队列非空”“仅外部队列非空” 三个分支分别添加注释，说明决策依据。

五.总结

在完成题目集1-3的单部电梯调度程序过程中，我逐步对java有了新的认识学会使用不同的方法，以及通过封装，多态以及继承的方式将项目功能进行优化。

1.技术方面

我逐步掌握了面向对象设计的核心原则—— 单一职责原则从 “概念理解” 到 “落地实践”，类结构从 “单类耦合” 到 “多类解耦”，最终实现了 “电梯管状态、乘客管数据、队列管存储、控制管调度” 的模块化设计。同时，对队列、枚举、正则表达式等技术的应用也从 “简单调用” 提升到 “场景化设计”（如队列的去重校验、正则的输入解析优化）。不仅如此在编程方面的能力也有所提升。