电梯博客总结

一、前言

对这三次题目集的心得总结

首先这三次题目的侧重点是类的设计和分析，重在培养学生的设计能力和将类与类联系起来的能力，题目的难度适中（电梯除外），但电梯的主要问题是第一次迭代对于电梯的运行方式不太了解，和现实有区别，电梯运行不是从整体去考虑，而是通过比较内部和外部请求的头部及电梯的方向来运行，但由于题目样例所给的提示比较少，故在第一次迭代卡了很久，但后两次迭代，只需要添加类并修改一部分代码逻辑就可以了。

二、设计分析

题目集中的题目除电梯问题都会给出参考类图，故只分析电梯问题的设计。

第一次电梯题目的设计与分析

题目要求

设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。

类的设计

因为只需要一个电梯类，所以设计类为以下所示

Source Monitor分析结果：

分析和心得

由上面的Source Monitor分析的结果上可以看出，这次题目提交的代码主要的问题：
1.代码的平均函数和最大复杂度较高：为了判断电梯要去那一楼，用了太多if-else语句，本来通过判断表头和方向很快就可以判断出目标楼层，但是要考虑到某一个数组为空另一个不为空的情况，所以使if语句大大增多，从而使代码复杂度较高。另外判断出目标楼层的方法将判断目标方向也容纳进去了，一开始不太清楚怎么判断目的方向，所以变得有点像面向过程了，但这个问题在第二次迭代得到了解决
2.平均深度和平均方法较大：这是只有一个类所造成的，不可避免，在第二次迭代经过分类之后就可以解决。
3.代码的注释很少，可读性比较差：应该养成注释习惯，方便阅读。

第二次电梯题目的设计与分析

题目要求

在第一次电梯迭代的情况下，对代码进行类的设计并且过滤重复且多余的请求。

类的设计

题目给出了参考类图但结合第一次迭代的代码设计类图为

·Elevator类：
负责管理电梯的状态，包括当前楼层（currentFloor）、运行方向（direction）、工作状态（state）等信息。
提供设置和获取电梯相关属性的方法，如设置当前楼层、运行方向、状态等。
具备对楼层合法性进行校验，确保电梯运行相关操作的合理性。
·State类：定义电梯的工作状态，如运行中和停止，用于标识电梯当前所处状态。
·Direction类：定义电梯运行方向，包括向上、向下和空闲，用于指示电梯的移动方向。
ExternalRequest类：用于封装电梯的外部请求信息，包括请求楼层和请求方向，方便对 外部请求进行管理和传递。
·Controller类：
协调电梯和请求队列之间的工作。
处理电梯请求，根据请求队列中的请求，控制电梯的运行方向、楼层停靠等操作。
包含对请求队列进行操作以及处理电梯运行逻辑相关的方法。
·RequestQueue类：
管理电梯的内部请求和外部请求。
提供添加、获取、设置内外部请求列表的方法，便于对各类请求进行集中管理和调度。
·Main类：程序的入口类，通过 main 方法启动整个电梯控制系统程序，进行初始化等相关操作 。
Source Monitor分析结果：

分析和心得

由上面的Source Monitor分析的结果上可以看出，这次题目提交的代码经过分类和注释后只以下的问题：
1.代码的平均函数和最大复杂度较高：为了判断电梯要去那一楼，用了太多if-else语句，本来通过判断表头和方向很快就可以判断出目标楼层，但是要考虑到某一个数组为空另一个不为空的情况，所以使if语句大大增多，从而使代码复杂度较高。并且解决了判断目的方向和判断目的楼层为一个方法的问题。
2.直到第二次迭代才彻底理解题意，电梯代码可以再精炼一点。由于之前的代码还是存在逻辑问题，这次迭代弥补了之前的缺陷，优化了代码逻辑。

第三次电梯题目的设计与分析

题目要求

这次的电梯问题除了添加乘客类和取消乘客请求类，运行方式也有所改变：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）

类的设计

题目给出了参考类图但结合原来的设计类图代码设计这次的类图为

·Elevator类：
负责管理电梯的状态，包括当前楼层（currentFloor）、运行方向（direction）、工作状态（state）等信息。
提供设置和获取电梯相关属性的方法，如设置当前楼层、运行方向、状态等。
具备对楼层合法性进行校验，确保电梯运行相关操作的合理性。
·State类：定义电梯的工作状态，如运行中和停止，用于标识电梯当前所处状态。
·Direction类：定义电梯运行方向，包括向上、向下和空闲，用于指示电梯的移动方向。
·Passenger类：
用于封装乘客相关信息，记录乘客的出发楼层和目的楼层 。
提供设置和获取出发楼层、目的楼层以及出行方向的方法，方便管理乘客的出行请求信息。
·Controller类：
协调电梯和请求队列之间的工作。
处理电梯请求，根据请求队列中的请求，控制电梯的运行方向、楼层停靠等操作。
包含对请求队列进行操作以及处理电梯运行逻辑相关的方法。
·RequestQueue类：
管理电梯的内部请求和外部请求。
提供添加、获取、设置内外部请求列表的方法，便于对各类请求进行集中管理和调度。
·Main类：程序的入口类，通过 main 方法启动整个电梯控制系统程序，进行初始化等相关操作 。
Source Monitor分析结果：

分析和心得

由上面的Source Monitor分析的结果上可以看出，这次题目提交的代码同样是之前的问题：
1.代码的平均函数和最大复杂度较高：为了判断电梯要去那一楼，用了太多if-else语句，本来通过判断表头和方向很快就可以判断出目标楼层，但是要考虑到某一个数组为空另一个不为空的情况，所以使if语句大大增多，从而使代码复杂度较高。并且解决了判断目的方向和判断目的楼层为一个方法的问题。
2.本来只需要解决原来代码的一部分逻辑就可以，因为第二次迭代后的代码已经比较成熟了，但理解错了题意，没有把乘客类中应该放到队尾的时候放到队尾，导致总有测试点过不了，当发现问题所在后对删除方法进行修改后就可以了

三、踩坑心得

1.千万不要理解错题意，不要想当然。
2.在有必要的时候可以通过列举来找规律，有时候通过列举可能比想更快找到规律。
3.一开始的代码，总出现运行超时，本来以为是代码运行时间太久导致的，其实并不是，这种情况，一般是代码运行形成了无限循环。
4.对于大量的分支，要观察仔细一点，如果包含所有分支的话是不会在if-else语句之外再返回值的，当时因为这个提交时总是出现无限循环。
5.动态数组想要拿出第一个数，得先判断是否为空，再在分支里提出第一个数，否则会报错
6.还有尽量不要有太多分支，太麻烦了，可读性比较差，也比较容易出错。

四、改进建议

1.在理解题意的基础上，遵循单一原则，不要有交叉。
2.采用更好的算法，尽量减少分支，方便阅读。
3.养成注释习惯，方便理解。
4.在有框架的情况下，会更高效，也更清晰对要怎么做有思路。

五、总结

对于这一次大作业，学到了很多，完成了从C语言到JAVA的思维转变，明白了类与类之间的设计关系，好的框架可以使行为更高效，要充分的理解题意，明白题目的意思，封装可过滤掉与题目不相干的元素。动态数组的使用也很方便，可以通过相对应的方法很快捷的操作输出。这也是java提供的便利性。