电梯调度问题5-7次作业第一次总结性Blog

电梯调度问题5-7次作业第一次总结性Blog
一、前言
近期，我们在编程学习中接触到了一个关于电梯调度问题的系列题目，这个题目需要通过三次作业，完成两次迭代来逐步完善功能。电梯调度问题看似简单，实则内部逻辑错综复杂。

在第一次作业时，就需要精心梳理思路。因为它是后续迭代的基石，要准确把握电梯运行的基本规则，如处理乘客的内外部请求、判断楼层的有效性等。如果在第一次作业时思路混乱，代码结构松散、逻辑不清，后续的两次迭代就会举步维艰。这就好比建造高楼，地基不稳，上层建筑必然摇摇欲坠。

对于我而言，这个题目颇具挑战性。在三次作业中，我遭遇了诸多状况。第一次作业时，由于对输入输出格式理解不够透彻，代码中对楼层请求的边界条件判断失误，导致程序出现非零返回的情况。当时没有充分考虑到乘客请求楼层数可能高于最高楼层或低于最低楼层的情况，使得程序在处理这类异常输入时无法正常运行。

到了第二次作业，引入了新的规则，比如要处理连续相同的不合理请求。我在尝试对代码进行迭代更新时，因为第一次作业的代码逻辑不够清晰，新功能的添加与原有代码产生了冲突，进而出现了编译错误。在排查错误的过程中，我发现自己对类与类之间的调用关系梳理得不够明确，部分方法的参数传递也存在问题。

第三次作业难度进一步提升，要求更加全面地模拟电梯运行过程并准确输出。我尽管对之前的错误进行了修正，但由于对整体业务逻辑的把握仍有欠缺，导致程序在一些复杂请求场景下，给出的答案错误。比如在多个内外部请求同时存在且方向不同时，电梯的调度逻辑出现混乱，没有按照正确的优先级和规则进行运行。

接下来，我将深入剖析这三次作业的题目要求以及我的代码实现，仔细分析每一处错误产生的原因，总结经验教训，争取在后续类似的编程题目中能够更加得心应手。

*这三次题目级涉及到了以下知识点：
1、类与对象：方法重载
2、封装：类中的属性通过方法进行访问和修改，体现了封装特性，
3、继承与多态：虽然图中未明显体现继承，但枚举类型的使用在一定程度上体现了类型限定和多态思想，不同枚举值代表不同状态或方向。
4、输入输出处理
5、数据结构：使用LinkedList来管理请求队列
6、字符串处理
7、正则表达式的运用

*习题5的电梯题目：需构建电梯类并管理多种状态和请求队列。调度算法要考虑请求方向和顺序，逻辑复杂。输入处理需过滤无效请求，测试用例验证增加难度。整体需较强编程和逻辑能力。
*习题6的电梯题目：一方面，要处理无效及重复请求，增加了输入处理的复杂度；另一方面，严格的类设计要求，如乘客请求类、电梯类等。
*习题7的电梯题目：需在之前基础上迭代设计，引入乘客类并取消乘客请求类，遵循单一职责原则，对类设计要求更高。输入格式变动，处理外部请求逻辑更复杂，要将目的楼层加入内部队列。

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

行数：116
语句数：61
分支语句所占百分比：11.5%
方法调用语句数：19
带注释的行所占百分比：11.2%
类和接口的数量：2
每个类的方法数：4.50
每个方法的平均语句数：4.33
最复杂方法的行号：74
最复杂方法的名称：Main.main ()
最大复杂度：6
最深代码块的行号：52
最大代码块深度：5
平均代码块深度：1.97
平均复杂度：1.89
*小结：由于是初次接触电梯调度编程题目，面对冗长复杂的题目要求，我瞬间感到无从下手。由于缺乏经验，没有对问题进行细致拆解和规划，直接开始编写代码，并且仅使用了一个类来实现全部功能。这导致代码逻辑混乱不堪，不同功能模块相互交织，不仅增加了调试的难度，也使得后续修改和维护变得异常困难。而且，由于没有合理划分代码结构，代码的复用性极低，几乎无法应用于其他类似场景。最终，在测试过程中，程序暴露出诸多问题，输出结果与预期大相径庭，尽管反复修改，仍然未能完全实现题目要求，这次经历让我深刻认识到前期规划和代码结构设计的重要性。

2、题集六
（1）题目
电梯运行规则与前阶段单类设计相同，但要处理如下情况：
乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：
运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
（2）类图

由于上一次题目我对于逻辑的设计就比较混乱，所以这一次作业选择完全按照题目中所给的类图进行设计完成自己的代码
（3）sourcemonitor图

行数：244
语句数量：141
分支语句所占百分比：19.1%
方法调用语句数量：81
含注释的行所占百分比：2.9%
类和接口的数量：3
每个类的方法数量：9.00
每个方法的平均语句数量：5.00
最复杂方法的行号：146
最复杂方法的名称：Controller.processRequests ()
最大复杂度：25
最深代码块的行号：168
最大代码块深度：8
平均代码块深度：2.57
平均复杂度：5.57
*小结：由于首次作业中逻辑设计混乱，代码结构松散，导致后续调试困难重重。因此在第二次作业时，我决定严格依照题目提供的类图进行代码设计，期望借此改善代码质量。然而，在实际编写过程中，由于对类图的理解仅停留在表面，未能充分把握类与类之间的依赖关系、方法调用逻辑以及数据传递规则。这使得代码在运行时出现非零返回的错误，暴露出我对类图设计意图理解的不足，也让我意识到仅仅照搬类图远远不够，还需要深入理解其背后的设计思想和逻辑关系。

3，题集七
（1）题目
电梯运行规则与前阶段相同，但有如下变动情况：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<请求源楼层，请求目的楼层>，其中，请求源楼层表示乘客发起请求所在的楼层，请求目的楼层表示乘客想要到达的楼层。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：
运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
（2）类图

（3）sourcemonitor图

行数：374
语句数：192
分支语句所占百分比：19.8%
方法调用语句数：90
含注释的行所占百分比：2.7%
类和接口的数量：6
每个类的方法数：6.67
每个方法的平均语句数：3.28
最复杂方法的行号：190
最复杂方法的名称：Controller.processRequests ()
最大复杂度：8
最深代码块的行号：196
最大代码块深度：6
平均代码块深度：2.16
平均复杂度：1.97
小结：在本次作业中，我延续了上次参照题目类图进行代码设计的思路。通过类图中明确标注的方法名称，如Controller.processRequests()、Elevator.move()等，我尝试梳理每个函数应实现的具体功能，并对各模块的职责进行初步划分。然而，在将这些方法串联起来实现电梯调度的整体逻辑时，却遭遇了瓶颈。由于对类与类之间的交互机制理解不够透彻，在方法调用顺序、参数传递以及状态同步等关键环节上出现偏差，导致程序虽然能够顺利编译并运行，但始终没有任何输出。提交代码后，系统反馈答案错误，这让我意识到看似完整的代码结构背后，仍存在逻辑漏洞。不过，值得欣慰的是，相较于前两次作业，此次代码成功规避了非零返回和编译错误等基础性问题，这也让我看到了自己在代码规范和基础语法掌握上的进步。接下来，我将着重分析方法调用逻辑中的问题，进一步完善程序功能。
三、改进建议
1、对于我自己
由于我的代码未能通过测试点，所以我并没有太多的踩坑心得，逻辑错误才是核心问题。整个程序的逻辑设计犹如一座根基不稳的大厦，从整体架构到细节处理都存在很大的缺陷。这不仅导致代码无法实现预期功能，还在调试过程中带来了诸多困难。
对于后续代码的改进，我制定了详细且有针对性的计划。首先，我会投入大量时间和精力来滤清自己的思路。以电梯调度问题为例，我会先依据问题的需求和规则，独立设计出清晰的类图。在这个过程中，我会将每个类的具体功能、每个方法的输入输出和实现逻辑都进行细致的规划。同时，明确类与类之间的交互关系，比如是继承、依赖还是关联，确保各个模块之间能够协同工作。 其次，我会注重对一些小错误的改进。在之前的代码中，我曾在列表的使用、函数的调用等方面出现过错误，这些看似微不足道的问题却严重影响了程序的正常运行。因此，在后续编码过程中，我会更加严谨地对待每一行代码，仔细检查列表的边界条件、函数的参数传递等，避免此类错误的再次发生。 此外，我会更广泛地学习解决问题的方法。通过阅读优秀的代码示例、参考相关的技术文档和参加技术交流活动，不断拓宽自己的视野，更新自己的思路。我相信，只有不断学习和实践，才能逐步完善代码中的错误，提高自己的编程能力。
2、对于题目
1）建议题目表述更通俗化，避免使用过于晦涩的专业术语。目前部分题目因措辞复杂，导致理解困难，可优化表达，降低入门门槛，让学生更易抓住核心要求。
2）建议老师在给予充足独立思考时间后，提供部分代码思路。当学生陷入逻辑困境时，适当引导可帮助突破瓶颈，理解问题本质，避免因思路混乱反复试错。
3）已截止提交的题目中，仍存在较多易错点与细节问题。希望老师能针对典型错误和规范要求进行讲解，帮助学生掌握关键细节，提升代码质量与规范性。
4）建议细化测试点，增加测试点数量与覆盖范围。同时为测试点命名，方便学生明确未通过测试的具体模块，精准定位问题，提高调试效率。
四、总结
通过这三次电梯调度题目的反复实践，我收获颇丰。在技术层面，我掌握了正则表达式在输入验证中的应用，能够通过正则表达式精准识别电梯内外部请求格式，有效过滤无效输入；学会依据功能需求合理设计类结构，从最初的单类混乱编写到后期多类分工协作，逐步理解面向对象编程的核心思想。同时，我深刻体会到单一职责原则的重要性，将复杂功能拆解为独立方法，显著提升了代码的复用性与可维护性。

尽管在代码逻辑设计上仍然很糟糕，多次因复杂调度规则处理不当导致程序错误，但每一次调试纠错都是宝贵的学习机会。在这个过程中，我对Java语言的语法特性、类库使用以及异常处理机制有了更深入的理解，从最初对语法的生疏到现在能够独立完成其他练习题，编程能力得到了显著提升。

展望未来，我希望能够在后续作业中突破逻辑设计的瓶颈，将所学知识融会贯通，精心规划代码结构，严谨梳理业务逻辑，争取提交一次完全符合要求的代码。相信通过持续的学习与实践，我能够克服现有困难，在Java编程领域取得更大的进步。