第一次blog作业

一、前言：
本阶段三次题目集主要考察基础编程能力和算法构思，题量不多，但是对于提升个人编程能力和编程思维有着很大帮助。每次题目集的前几题难度不高，最后一两题提高难度，对个人的编程能力有着不小的挑战。

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


根据报表内容，分支语句占比33.3%，反映出代码中条件判断逻辑较多，需优化条件逻辑，避免过度嵌套。方法调用数为41次，显示出一定的交互复杂度。每类平均方法数为1.8，结构较为简单，但平均每方法语句数10.22，且最大复杂度为8，表明部分方法逻辑较复杂，需关注优化。

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

电梯运行规则与前阶段单类设计相同，但要处理如下情况：
乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>
设计必须符合如上要求（包含但不限于乘客请求类、电梯类、请求队列类及控制类，其中控制类专门负责电梯调度过程）
第二次迭代代码的SourceMontor报表内容和PowerDesigner相应类图如下：


根据报表内容，分支语句占比22.9%，较第一次迭代有所下降，表明条件判断逻辑占比减少。方法调用数达102次，显示模块间交互频繁，但高频的方法调用也提示要关注耦合度。类数量为7个，每类平均方法数为4.71，平均每方法语句数为4.06，但最大复杂度为12，说明存在个别复杂方法需优化。第二次迭代相较于第一次迭代引入了Controller和RequestQueue，使系统架构更清晰，职责更单一，Elevator类的方法细化提升了控制的精准性。这些设计虽然增加了类的数量，但增强了系统的可扩展性。

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

电梯运行规则与前阶段相同，但有如下变动情况：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
设计必须符合如上要求（包含但不限于设计电梯类、乘客类、队列类以及控制类）
第三次迭代代码的SourceMontor报表内容和PowerDesigner相应类图如下：


根据报表内容，第三次迭代的代码最大复杂度为14，代码规模与复杂度进一步提升，高频方法调用112次，反映出模块间交互紧密，需关注耦合度的影响。Passenger类的引入使系统更具现实意义，Controller类的细化（如handlePassengers方法）体现了需求的深化。但是类图的复杂化也直接导致代码量与交互频率增加。

三、采坑心得：
在最开始对题目的理解错误，未能理解题目的逻辑，导致后续的思考方向几乎全部错误。在设计类及其方法的时候考虑不周，有时甚至违反了单一职责原则。同时代码缺少注释，某些命名不能很好的反映其职责，导致代码的可读性很低，这给后续自己修改代码创造了不少麻烦。

四、改进建议：
1.将各个类按职责进一步进行细分，同时要严格遵守迪米特法则和单一职责原则。
2.可以的话在代码后适当添加注释，同时命名要反映对应职责，增强可读性。

五、总结：
通过本阶段三次题目集我了解了SRP单一职责原则，学到了正则表达式，ArrayList/List的使用和类与类之间的关系（如依赖，聚合）。但这些知识掌握并不熟练，日后仍需继续练习正则表达式，ArrayList/List的使用，同时研究类与类之间的关系并学习如何设计类结构，为下一阶段的学习打好基础。
也建议在今后教学活动中加入更多的学生交流环节，让学生有更多机会可以交流自己编程时遇到的问题、编程后的心得。