BLOG-1

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

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

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

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

1
20
❤️,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
实现方式
设计1个电梯类根据输入输出进行处理
我并没有写出来
我的运行结果是答案错误，我没有完全了解电梯的运行规则

我尝试完成这个电梯调度程序时遇到了不少挑战，让我分析一下存在的问题和心路历程：

遇到的问题

1. 请求队列管理复杂
   需要同时管理内部请求队列和外部请求队列（区分上行/下行）

如何高效地根据当前方向和位置筛选合适的请求是个难点

2. 方向判断逻辑混乱
   电梯运行方向的确定需要考虑多个因素：

当前是否有同方向请求

同方向请求处理完后如何切换到反方向

空闲状态下的方向决策

3. 状态转换不清晰
   停止、移动、开门、关门等状态的转换条件不够明确

在什么情况下应该改变方向判断不准确

4. 边界条件处理
   无效楼层请求的验证

电梯到达最小/最大楼层时的行为

请求队列为空时的空闲状态处理

心路历程
初期阶段
开始时代码结构比较混乱，试图一次性处理所有逻辑，导致方向判断和请求筛选的代码纠缠在一起，难以维护和调试。

中期调整
意识到需要将功能模块化：

分离请求解析逻辑

独立的方向判断函数

清晰的状态管理

后期优化
通过测试用例发现了很多边缘情况，比如：

电梯在最高层收到下行请求

多个同方向请求的优先顺序

开门关门时新请求的处理

感悟
分解问题很重要：将复杂的电梯调度分解为方向判断、请求筛选、状态管理等小模块后，问题变得清晰很多。

测试驱动开发：先写测试用例再实现功能，能更好地覆盖各种边界情况。

状态机思维：电梯本质上是一个状态机，明确定义状态和转换条件至关重要。

算法设计能力：这类调度问题考验的是如何设计高效且正确的算法逻辑。

虽然最终可能没有完全实现所有功能，但这个过程让我深刻体会到系统设计的重要性，以及如何将现实世界的问题转化为可执行的代码逻辑。
OOP题目集2
作业要求:
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。

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

乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<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
❤️,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
❤️,UP>
❤️,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
我还是没写出来

感悟与收获

1. 面向对象设计的重要性
   单一职责原则确实能提高代码的可维护性

良好的类设计可以减少后续修改的复杂度

接口定义清晰有助于团队协作

2. 算法思维需要加强
   电梯调度本质是一个经典的算法问题

需要将现实问题抽象为可计算的模型

算法效率直接影响程序性能

3. 测试驱动开发的必要性
   先写测试用例能更好地理解需求

边界情况的测试尤为重要

自动化测试能提高开发效率

4. 问题分解能力
   将复杂问题分解为小模块是关键

每个类解决一个特定问题

模块间通过清晰接口通信

改进方向
加强面向对象设计训练 - 多练习类图设计和职责划分

深入学习设计模式 - 特别是状态模式、策略模式在本题中的应用

提升算法能力 - 多练习类似的调度算法问题

完善测试方法 - 学习更系统的测试用例设计方法

这次迭代开发让我深刻体会到，好的程序设计不仅仅是让代码运行起来，更重要的是创建出可维护、可扩展、易于理解的代码结构。虽然最终可能没有完全实现所有功能，但这个过程对提升我的软件设计能力很有帮助。
OOP题目集3
作业要求:
对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，具体设计可参考如下类图

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

乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
注意：本次作业类设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类），凡是不符合类设计要求此题不得分，另外，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
感悟与收获

1. 架构设计的重要性
   好的类设计能够适应需求变化

单一职责原则在迭代开发中体现价值

清晰的接口定义有助于降低耦合度

2. 需求分析的深度
   表面简单的需求变更可能带来巨大的实现复杂度

需要深入理解每个变更对系统的影响

提前识别潜在的技术风险

3. 算法设计的灵活性
   调度算法需要具备一定的适应性

考虑各种边界情况和异常流程

算法效率与正确性的平衡

4. 测试覆盖的全面性
   新功能需要更全面的测试用例

回归测试确保原有功能不受影响

性能测试在复杂场景下尤为重要