第一次大作业———电梯迭代blog

一前言

这次的电梯迭代作业真的是把我虐杀了，这也说明我自己的java编程能力还有欠缺，但是也是有进步的，这也是我这个新手第一次接触这种大作业，当我看到第一次的题目集时，简直是看都不想看，以至于我在题目集开始的三天后才开始看这个题目集，看完到理解就已经换了很多时间，看完也是无从下手，只能先把一些基础的东西写上去，根本的逻辑还是不是很理解怎么写下去，想了很久才开始慢慢的写核心代码，到最后提交完再看一遍我的代码，也就慢慢的了解了，在之后的两次大作业时，虽然不会有畏惧感，写是写出来了，但是答案却是错误的，改了很多遍都是一样的结果，太扎心了。

二 设计与分析

对电梯题目的设计与分析：

---

第一次题目集分析：

题目要求：

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

类图设计：

Source Monitor分析结果：

代码整体分析：

由于是第一次的大作业，对这个类的单一职责原则还不是很清楚，所以代码中只有一个主类和电梯类，加起来就151行代码，代码中的注释也很少，导致代码的可读性和理解性偏低，有四分之一的分支语句，分支结构带来很多执行路径，使程序逻辑复杂性增加，调试和测试工作量也会增大，并且较多的方法调用语句，调用关系复杂，所有的核心逻辑都在电梯类一个类中，导致工作量大，代码难理解，在process中也很多if-else语句，代码总体上看起来偏向于面向对象的结构，还是有很大的改进空间的。

第二次题目集分析：

题目要求：

这第二次的电梯作业是在第一次作业的基础上进行迭代，在乘客请求不合理，具体为输入时出现连续的相同请求，程序自动忽略相同的多余输入。

类图设计：

Elevator类：表示电梯的相关属性和操作
State枚举类：列举出电梯的状态常量
Direction枚举类：列举出电梯运行方向的常量
ExternalRequest类：表示电梯外部请求
RequestQueue类：管理电梯请求队列
Controller类：是电梯运行的控制器，核心逻辑，协调电梯和请求对列来处理输入的东西

Source Monitor分析结果：

代码整体分析：

在第二次的电梯作业中，因为题目中给出了参考类图，所以相对的工作量不会很大，也更有思路，相较于第一次的题目集，这次的代码基本符合了类的单一职责原则，有276行代码，对目前的我来说也算是多的，有五分之一的分支语句，方法的调用语句有118条，方法调用频繁，但是代码的注释依然还是没有，严重影响了代码的可读性和可维护性，平均每个类的方法较多，方法规模小，功能单一，整体代码复杂程度适中，但存在局部复杂点，以及存在一些逻辑错误，毕竟我也没有将此次的题目集电梯题做出来，代码存在局部复杂度高的地方，还有改进的地方。

第三次题目集分析：

题目要求：

第三次的大作业，取消乘客请求类，新添加了乘客类，输入的方式也不一样了，外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾），但是题目逻辑和第二次的大作业大差不差。

类图设计：

Elevator类：表示电梯的相关属性的和操作
State枚举类：列举出电梯的状态常量
Direction枚举类：列举出电梯运行方向的常量
RequestQueue类：管理电梯的请求队列
Controller类：是电梯运行的控制器，核心逻辑，协调电梯和请求对列来处理输入的东西
passenger类：用来表示乘客的请求信息

Source Monitor分析结果：

代码整体分析：

由于与第二次大作业相差不大，所以代码的行数和语句数还有分支语句也没有变化很大，依旧是没有注释，类和接口数多了一些，方法规模较小，平均深度还行，但是最大深度较大，局部逻辑嵌套较深，增加理解与调试难度，依然存在局部复杂度过高的问题，逻辑几乎与第二次相同，所以结果可想而知的是失败了，但也是满足了类的单一职责原则。

三 踩坑心得

虽然在这三次的题目集中我都折戟沉沙了，但是也收获了很多，也发现了很多自身存在的问题，在一开始做这个题目时，我以为是输入一个就处理一个，然后我就自以为是的开始写代码了，写完运行我才发现是一次性的输入乘客请求，所以在还没有完全理解好题目时，不要盲目动手，不然都是无用功，电梯运行时是处理完还有同向的请求时才会改变运行方向，而不是处理完一个之后如果后面有反向的请求就改变方向了，如果不小心进入这个理解层面，那代码逻辑基本上是错误的。还有在判断电梯运行方向时，要先判断电梯的状态是UP还是DOWN还是IDLE，还有在控制电梯运行的Controller类中的控制电梯向上和向下运行的方法中，要注意更新电梯的当前楼层同时也要注意是否超过了最大楼层或者最小楼层，不然逻辑会出现错误，在添加请求时，注意不要将外部和内部的请求搞混，在第三次的大作业中，输入输入的时候很好辨别，但是在Main类中添加对列时，由于添加内部请求时要加上电梯的当时的楼层，很容易搞混。

四 改进与建议

从踩坑的地方中可以得到很多的改进，最大需要改进的地方那就是写注释，在第三次的大作业中，若有注释在旁边的话，那么理解起来会方便很多，也不会那么容易被自己的代码搞混，我现在重新看我的源码时，几乎是不怎么看得懂逻辑的，逻辑比较混乱，所以写注释是非常需要的，也要时刻的注意题目要求，不要一拿到题目就开始敲代码，先确定类图和思路，把一切步骤准备好了就可以编写代码了。在提供了参考类图的情况下也下不出正确的代码，需要多多的去理解类与类之间的关系，否则就算给了类图也写不出来。

五 总结

这次的大作业是一个电梯的迭代作业，一次一次的递进，题目数量也从一开始的五题后面慢慢的变成三题，也说明的代码的难题程度了，第一次的电梯作业可谓是够折磨了，在题目集结束前才做完，之后的两次电梯作业有了第一次电梯作业的基础，事实上是简单了一点，让我们搞懂多个类之间的关系，和设计类，但是我没做出来，也是十分的不甘心，第三次相对于第二次的电梯作业只是稍微的改了一下输入，由于第二次都没有做出来，第三次可想而知了，但是也对类的设计和类之间的关系有了一些理解，以及对类的单一职责原则有了清楚的认识和实践，也学会了基本的正则表达式的运用，希望在之后的大作业中可以尽自己的全力将问题解决，也要多多适应与在自己的代码基础上写上注释方便理解，以及先深度思考题目的要求来写代码，不然还是会出现像这次的情况一样的逻辑错误，导致一环接一环的做不出来题目，通过这次的大作业也将自己的思维方式从面向过程向面向对象的转化，对类的单一职责原则更加的理解了，也初步的了解到了正则表达式是如何使用的。