第一次Blog作业

一，前言

在经历过三次电梯题目集的摧残后，有了一些自己的感受和疑惑，作为JAVA的第一次大作业，难度是毫无疑问的。在编写代码的过程中我也遇到了许多的问题，该如何去设计结构？如何使代码更为简洁？这一次的题目很好的将我们所学和现实生活相结合，在现代城市中，电梯是高层建筑中不可或缺的交通工具。电梯的调度算法决定了电梯的运行效率和乘客的等待时间。所以在这几次的作业中我也在努力对代码进行调试，已达到减少代码运行时间的目的。

二，设计与分析

第一次作业：单部电梯调度程序

题目要求：

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

Source Monitor分析结果：

代码整体分析：

由于第一次做题，在设计结构的时候并未过多考虑其他类的设计，所以我只设计了Main和Elevator两个类。这也为我在后续作业的完成带来了许多麻烦。代码中的注释占比较低，可能会对代码的可读性和后期维护产生一定影响，尤其是当其他开发者接手代码时，理解代码意图可能会花费更多时间。尽管目前复杂度低，但 26.5% 的分支语句意味着有条件判断逻辑，若需求变更或场景增多，可能因考虑不全导致逻辑错误。

第二次作业：单部电梯调度程序（类设计）

题目要求：

电梯运行规则与前阶段单类设计相同，但要处理如下情况：
乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为<3>

类图设计：

Source Monitor分析结果：

代码整体分析：

在第二次的电梯作业中，因为题目中给出了参考类图，所以相对的工作量不会很大，也更有思路。每个类的方法数多达 29 个，这表明类可能承担了过多不同的功能，不符合单一职责原则，增加了类的维护和测试难度。方法调用语句数为 86 条，较多的方法调用可能会增加代码的耦合度，影响代码的独立性和可复用性。由于我没有将此次的电梯题做出来，代码存在局部复杂度高的地方，还有改进的地方。

第三次作业：

题目要求：

对之前电梯调度程序再次进行迭代性设计，加入乘客类（Passenger），取消乘客请求类，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客类、队列类以及控制类，电梯运行规则与前阶段相同，但有如下变动情况：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）

类图设计：

Source Monitor分析结果：

代码整体分析：

这是第三次电梯题，由于是在第二次的基础上进行的，所以我同样也没有写出来。从这次的分析结果来看，不难发现我一直都有注释比例低的问题，而较低的注释比例会导致代码可读性变差。当其他开发人员接手代码时，由于缺少注释，理解代码逻辑和功能意图会花费更多时间。除此以外，平均每个方法的语句数较多，平均每个方法有 4.22 条语句，说明方法内部逻辑可能较为复杂，没有很好地进行方法拆分，将复杂逻辑拆分成更小、更易管理的子方法。

三，踩坑心得：

虽然这三次的题目我都没能写出来，但是在编写代码的过程中，我也注意到了许多的问题。首先就是在每次题目的代码中注释比例低，由于题目有一定难度，这一问题直接导致了在我第二天检查代码时，回忆我所写代码功能的时间较长，增加了阅读代码的难度。其次就是对题目的理解不充分，在没有充分了解题目的情况下，就开始编写代码，导致经常无法通过测试点。还有就是，在设计类的时候，会出现单个类中方法过多，增加了类的维护和测试难度。

四，改进与建议

1，增加注释：在编写代码时，及时、详细地添加注释，不仅要对关键代码段的功能进行说明，还要对一些复杂的算法、逻辑判断等进行解释。对于难度较高的题目，注释能有效帮助后续回顾代码，降低阅读难度。
2，充分理解题目：拿到题目后，先认真审题，明确题目要求、输入输出格式、测试用例限制等。可以尝试手动推导一些简单的测试用例，确保对题目有全面且深入的理解后，再开始编写代码，以提高代码通过测试点的概率。
3，优化类的设计：遵循单一职责原则，将功能相近或相关的方法归为一类，避免单个类中方法过多。对于功能复杂的类，可以考虑拆分成多个小类，降低类的维护和测试难度，提高代码的可维护性和可扩展性。

总结：

这次的大作业是一个电梯的迭代作业，一次一次的递进，题目数量也从一开始的五题后面慢慢的变成三题，也说明的代码的难题程度了。我在后续的代码编写过程中应注意提高代码的简洁性和可读性。在编程过程中注意注释比例低、对题目理解不充分、类设计时单个类方法过多等问题。争取在下一次的作业中完成题目要求，加强调试的能力,面对一些逻辑问题，更好、更快地找出并解决。