第一次Blog作业

前言：

这次电梯调度程序的设计与实现，对我来说不仅是一次技术上的探索，更是一次对耐心、毅力和思维能力的全面考验，每一步都充满了曲折与不易。在最开始，面对复杂的电梯调度规则和多样的请求处理需求，我感到有些手足无措。调试过程中频繁出现错误，甚至一度让我感到挫败。但正是这些困难，让我更加坚定了不断学习和改进的决心。我一遍又一遍地调试代码，查阅资料，优化设计，直到最终实现了符合要求的程序。这个过程让我深刻体会到，技术的提升不仅仅是知识的积累，更是对问题解决能力和心理素质的考验。

程序的设计与分析

第一次电梯调度问题

设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。

电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。

使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。

请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。

输入格式:

第一行输入最小电梯楼层数。

第二行输入最大电梯楼层数。

从第三行开始每行输入代表一个乘客请求。

电梯内乘客请求格式：<楼层数>

电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。

当输入“end”时代表输入结束（end不区分大小写）。

输出格式:

模拟电梯的运行过程，输出方式如下：

运行到某一楼层（不需要停留开门），输出一行文本：

Current Floor: 楼层数 Direction: 方向

运行到某一楼层（需要停留开门）输出两行文本：

Open Door # Floor 楼层数

Close Door

根据题意有以下类图可以满足题目需求：

但是一开始编写时一直碰到运行超时的问题，电梯下降至六楼后停止，当时未能及时找出原因。第一次电梯调度程序将所有功能（电梯状态管理、请求队列管理、调度算法）集中在一个类中。使用简单的方法实现电梯的基本运行逻辑。这样实现简单，代码量少，适合快速开发小型程序。逻辑集中，易于理解和调试。但是违反了单一职责原则（SRP）导致类职责过多，代码臃肿。扩展性差，难以应对更复杂的需求（如多电梯调度、并发请求等）。代码复用性低，难以将功能模块化。

第二次电梯调度问题

第二次问题开始涉及到多个类的设计。将功能拆分为多个类，如Elevator、PassengerRequest、RequestQueue和ElevatorController。并且每个类负责一个明确的职责，符合单一职责原则（SRP）。这样设计职责清晰，代码结构更合理。扩展性增强，便于后续功能扩展（如多电梯调度、并发请求处理）。代码复用性提高，模块化设计便于维护和测试。以下类图可以符合需求

第三次电梯调度问题

1. 第三次电梯调度在第二次的基础上进一步优化与改善。在第二次迭代的基础上，进一步优化类的职责和交互逻辑。增加对无效请求的处理（如无效楼层、重复请求），提高程序的健壮性。功能更加完善，能够处理更复杂的场景。代码健壮性增强，能够自动忽略无效或重复请求。符合软件工程的最佳实践，易于团队协作和长期维护。以下类图符合需求：

对时间复杂度的分析

迭代版本	添加请求时间复杂度	处理请求时间复杂度	总体时间复杂度
第一次迭代	O(1)	O(n)	O(m * n)
第二次迭代	O(log n)	O(log n)	O(m * log n)
第三次迭代	O(log n)	O(log n)	O(m * log n)

• 第一次迭代：时间复杂度较高，适合请求队列较短的情况。
• 第二次迭代：通过引入优先队列，显著优化了时间复杂度。
• 第三次迭代：在保持时间复杂度不变的情况下，增加了健壮性。

心得

在三次电梯调度程序的设计与实现过程中，我不仅掌握了技术知识，还深刻体会到了编程中的一些重要原则和方法。以下是我的心得体会：

在第一次迭代中，我将所有功能集中在一个类中，导致代码臃肿、职责混乱。随着功能的增加，代码变得越来越难以维护。通过第二次和第三次迭代，我逐渐理解了单一职责原则（SRP）的价值：将功能拆分为多个类，每个类只负责一个明确的职责。这不仅使代码结构更清晰，还提高了可扩展性和可维护性。在设计程序时，尽量遵循单一职责原则，避免“上帝类”的出现。从单一类到多类设计，再到优化与完善，每一次迭代都在前一次的基础上进行改进。这种渐进式的设计方法让我能够逐步解决问题，而不是一次性面对所有挑战。在开发过程中，采用迭代设计方法，逐步优化程序，避免一次性追求完美。在第三次迭代中，我增加了对无效请求和重复请求的处理，提高了程序的健壮性。这让我意识到，程序不仅要满足功能需求，还要能够应对各种异常情况。在设计程序时，始终考虑健壮性，处理可能的异常情况，避免程序崩溃或产生错误结果。在实现过程中，我遇到了许多问题，例如逻辑错误、类之间的交互问题等。通过调试和测试，我逐步定位并解决了这些问题。这让我深刻体会到，调试和测试是编程过程中不可或缺的一部分。在开发过程中，注重调试和测试，确保程序的正确性和稳定性。

总结

三次迭代从单一类设计逐步演变为多类设计，体现了从简单到复杂的设计过程。每次迭代都在前一次的基础上进行优化，逐步提高程序的质量和性能。第一次迭代忽视了设计原则，导致代码臃肿。第二次和第三次迭代逐步引入单一职责原则（SRP），使代码结构更清晰、职责更明确。第一次迭代适合小型项目或快速原型开发。第二次和第三次迭代适合中型和大型项目，特别是需要高扩展性和可维护性的场景。简单设计开发效率高，但代码质量低。复杂设计开发效率低，但代码质量高。在实际开发中，需要根据项目需求和团队能力选择合适的方案。