前言
在三次对单部电梯调度程序类的设计中，题目由一个类到多个类，由未考虑单一职责原则到类设计遵循单一职责原则(SRP)，与此同时乘客的请求变得更加详细，都使得我们需要不断的对原来的程序进行修改和完善，下面是我对我所编写的三次程序设计的分析。
题目中的知识点
在第一次作业中：本次题目中使用的调度算法为LOOK算法，同时对于电梯请求队列的管理主要用到了String类来进行存储与进行分析，该程序的核心是对请求的排队和处理，这天然适合使用队列这种 “先进先出”（FIFO）的数据结构。并且Java 中的 LinkedList 类实现了 Queue 接口，可以方便地进行 add()（入队）、peek()（查看队首）和 poll()（出队）操作。
在第二次作业中：本次题目相对于第一次题目来说，增加了对于类的设计要遵循单一职责原则这一要求，并且要对内外的队列要求进行区分，要考虑到类与类之间的关系。
在第三次作业中：在本次作业中新加入了乘客类（Passenger），并且取消了乘客请求类，对电梯的状态与运行方向有了更严格的要求，对于类与类之间的关系有了更深刻的使用。
难度：
对于这三个题目而言，第一个虽然是最基础的一个，但是也是最为困难的，因为在第一次作业中，我们必须要搞清楚题目的意思与要求，如果在第一次作业中没有理解题目的要求，那么更加无法完成后面的两个题目，这个题目要求我们同时运用多个领域的知识，并且将它们有机地结合起来，对于第一个作业的题目要求而言，我们需要根据当前楼层、当前运行方向、内部请求队列的队首、外部请求队列的队首这四个因素来决定下一个目标楼层，从而完成我们的程序设计。在第二次作业中，它是要求在第一次作业的基础上进行迭代性设计，要求解决电梯类职责过多的问题，并且类设计要求遵循单一职责原则（SRP），这次作业相对于第一次作业来说难度有了部分提升，但是如果已经在第一次作业中明白了题目的要求与电梯的运行逻辑，那么在第二次作业中的程序也会相对来说更容易完成。第三次作业时在第二次作业的基础上又进行了一次迭代性设计，在本次作业中新加入了乘客类（Passenger），并且取消了乘客请求类，相对来说代码程序逻辑并没有太多的改动，虽然对于第一次与第二次作业来说，实现的功能更加严格了，但是难度也属于适中。
设计与分析
第一次作业：
题目：设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。
通过题目可以看出本次作业只要求考虑一个类，即所有的方法都在这个电梯类中，类图如下：
使用SouceMonitor对第一次代码进行静态分析，情况如下：
优点：
逻辑复杂度极低：该代码平均复杂度（Average Complexity）和最大复杂度（Maximum Complexity）均为 1，说明代码逻辑非常简单，几乎没有复杂的条件分支或嵌套逻辑。
代码结构较清晰：块深度（Block Depth）整体偏低，平均块深度（Average Block Depth）1.39，最大块深度（Maximum Block Depth）4，代码嵌套层级少，可读性较好。
基础可维护性有保障：类和接口数量（Classes and Interfaces）为 2，方法平均数量（Methods per Class）10.50，结构不算臃肿。
不足：
注释覆盖率不足：代码注释过少，使得代码可理解性下降。
模块化程度待提升：后续功能扩展，代码会逐渐变得臃肿，可维护性和扩展性会快速下降，缺乏清晰的模块划分（如分层、领域拆分等）。
分支灵活性可能不足：当前代码可能缺乏足够的逻辑灵活性，后续需求变更时可能需要大量重构。
第二次作业：
题目：对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类。
电梯运行规则与前阶段单类设计相同，但要处理如下情况：
- 乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
- 乘客请求不合理，具体为输入时出现连续的相同请求，例如
<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>
注意：本次作业类设计必须符合如上要求（包含但不限于乘客请求类、电梯类、请求队列类及控制类，其中控制类专门负责电梯调度过程），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次电梯程序提交到本次题目中测试）。
在这次作业中要求设计多个类，具体设计类图如下：
使用SouceMonitor对第一次代码进行静态分析，情况如下：
优点：
代码可读性有明显提升：
模块化初步成型：
不足：
核心方法逻辑复杂度高：
代码结构仍需优化：
部分方法职责过载：
与第一次作业代码的静态分析做比较，结果如下：
总结：第二次代码在可读性和基础模块化上有明显进步，但代价是核心方法的复杂度失控，出现了 “局部优化、整体失衡” 的情况。若要进一步优化，需重点拆解Main.main()的职责，将集中的逻辑拆分到多个独立方法或类中，同时考虑按功能拆分文件，避免 “单文件承载所有逻辑” 的问题。
第三次作业：
题目：对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类。
电梯运行规则与前阶段相同，但有如下变动情况：
- 乘客请求输入变动情况：外部请求由之前的
<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层> - 对于外部请求，当电梯处理该请求之后（该请求出队），要将
<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
注意：本次作业类设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类），凡是不符合类设计要求此题不得分，另外，PTA得分代码界定为第一次提交的最高分代码（因此千万不要把第一次及第二次电梯程序提交到本次题目中测试）。
第三次作业相对与于第二次作业来说，它去掉了乘客请求类，加入了乘客类，类图如下：
第三次作业的代码我并没有通过测试点，故无法给出该题目的静态分析图。
对于该题目来说，其实相较于前面两个题目而言，并没有要做太多的修改，但是由于我没有第一时间理解题目的意思，故始终无法通过测试点。
采坑心得：
在本次完成作业的过程中我也遇到了许多问题，首先是在第一次作业中，由于我在开始写代码时并没有完全理解题目的意思，导致我的代码始终无法通过测试点，后来我发现，我的的代码是优先处理内部队列的，内部为空才会给外部队列赋值，但是题目的要求是同时取出内部和外部队首，然后判断去处理谁的请求，这种情况下外部请求的队首，必须是要在电梯的“前方”，并且方向与当前电梯方向相同，才返回外部请求，在电梯的前方的意思是，例如电梯在五楼，有一个七楼向上的外部请求，，这就是前方，如果是有一个三楼向上的请求，这就是在电梯的后方，这就导致了我的代码逻辑在一开始时就是错误的，所以如果不对这个进行更改，那么后面不管怎么优化都无法通过测试点，再后面我对代码逻辑进行了修改后，才通过了测试点，完成了这次作业。在第二次作业中，题目的要求有了变化，它由原本的一个类变为了多个类，在进行了几次修改后也完成了该题目，在这一题中，开始的错误是我的程序在每次输出时都会在最后额外输出一行，后来也修改了代码的输出解决了该问题。
改进建议：
