第一次Blog作业：JAVA电梯调度
前言：
拿起第一份java大作业，看得出来这次作业考察的主要内容还是对于类的描写和关系之间的组件，就比如说队列与运动关系之间的内容。还有就是考察了一些语法的运用，比如正则表达式比较输入内容的正确性，和一些列表或者数组的运用。
题目量倒是不算是特别多，第一次5题，后两次就只有三四题😁。到算不上过于忙碌，但是在难度上的区别就有点大，大作业的梯度问题对于一开始学习Java的学生可能不算简单，尤其是还在不清楚具体如何运动和运动细节的内容情况下。也导致了一开始的作业通过率十分低。但是有了第一次的铺垫来说就好很多了，好了，接下来就是代码的分析了。
第一次电梯作业：
题目：
设计一个电梯类，具体包含电梯的最大楼层数、最小楼层数（默认为1层）当前楼层、运行方向、运行状态，以及电梯内部乘客的请求队列和电梯外部楼层乘客的请求队列，其中，电梯外部请求队列需要区分上行和下行。
电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。-每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
使用键盘模拟输入乘客的请求，此时要注意处理无效请求情况，例如无效楼层请求，比如超过大楼的最高或最低楼层。还需要考虑电梯的空闲状态，当没有请求时，电梯停留在当前楼层。
要求：
请编写一个Java程序，设计一个电梯类，包含状态管理、请求队列管理以及调度算法，并使用一些测试用例，模拟不同的请求顺序，观察电梯的行为是否符合预期，比如是否优先处理同方向的请求，是否在移动过程中处理顺路的请求等。为了降低编程难度，不考虑同时有多个乘客请求同时发生的情况，即采用串行处理乘客的请求方式（电梯只按照规则响应请求队列中当前的乘客请求，响应结束后再响应下一个请求），具体运行规则详见输入输出样例。
输入格式:
第一行输入最小电梯楼层数。
第二行输入最大电梯楼层数。
从第三行开始每行输入代表一个乘客请求。
电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，
其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）。
输出格式:
模拟电梯的运行过程，输出方式如下：
运行到某一楼层（不需要停留开门），输出一行文本：
Current Floor: 楼层数 Direction: 方向
运行到某一楼层（需要停留开门）输出两行文本：
Open Door # Floor 楼层数
Close Door
分析问题：
1：强调内外请求具有区别性
2：根据测试样例与前提要求确定"方向优先原则"
3：对于输入格式要求有相应控制
4：多种情况下具有多种运动类型
5：先判断，再运动
设计类图：
设计了四个主大类来分成前面提到的板块，后期可以缓慢修改。但此时其实也暗示了后期的复杂与逻辑复杂度高。
写完代码参数分析：
可以看到，这样设计出来的代码行数会偏多，并且复杂指数偏大，对于最开始的编写会有较大的挑战性，但是好在只要完成了第一次内容的正确编写，会为后续内容提供极大便利。
思路讲解：
注意到同向优先的原则，一开始是没有丝毫思路可言的，在没有更好的解题方法下，我选择暴力分类进行强制判读，可能会导致语句支线过多复杂度过高，但是可以把问题解决，为了将判读和运行分开，我选择以两个板块进行：判断返回->查询运行。的方法进行，也算是减小一些逻辑复杂度，还有就是对于输入的地方，我选择先输入，再依次分组，这样可以防止在后续大作业中万一存在输入处的更改就能直接修改一小部分便直接完成。
问题与解决：
1：在编译错误全部排除后还是显示答案错误
解决：说明了这是处于逻辑层面上的问题，但是考虑到单步调试还是有点慢，我选择在每一处判读点新增加输出的内容，来根据接下来的内容输出判断是逻辑语句哪一条没有进入或者错误。
2：更改后虽然测试样例过了但是还是没有通过测试点
解决：找到已经过了的同学探讨其他测试样例情况，或者用新样例对照不同代码运行出来的结果判读语句问题
第二次电梯作业：
题目变化：
对之前电梯调度程序进行迭代性设计，目的为解决电梯类职责过多的问题，类设计要求遵循单一职责原则（SRP），要求必须包含但不限于设计电梯类、乘客请求类、队列类以及控制类，具体设计可参考如下类图。
电梯运行规则与前阶段单类设计相同，但要处理如下情况：
乘客请求楼层数有误，具体为高于最高楼层数或低于最低楼层数，处理方法：程序自动忽略此类输入，继续执行
乘客请求不合理，具体为输入时出现连续的相同请求，例如<3><3><3>或者<5,DOWN><5,DOWN>，处理方法：程序自动忽略相同的多余输入，继续执行，例如<3><3><3>过滤为
分析问题：
不出所料，相比于前一次的pta电梯作业，这次在输入控制上添加了不能重复的要求和最高，低楼层的限制。好在在一开始就考虑到这一点，所以在更改的时候只需要在输入类中添加输入前的要求判断保证数据正常才能输入到数组里，然后就是再细化类。
类图设计：
可以看到，这次设计完后类要多了很多，但是其实都是基于前面类的细化。
写完代码参数分析：
虽然复杂度还是很高，但是可以直接借助前面的代码直接进行修改，可以从行数看出来只做了十几行的调整。
思路讲解：
在输入的数据的时候就开始判断是否数据符合要求，只有符合要求的才能输入：重复就和数组前一个内容进行对比，最大最小就按照最开始输入的最大最小值进行对比。
问题与解决：
1：在点击运行的时候发现报错，访问了空位置
解决：找到了是处于最开始对比的时候，数组是空的，根本不存在前一个内容。直接访问会出问题。所以增加了if，else的判断。
第三次电梯作业：
题目更改：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
分析问题：
相比于前两次内容，这次直接把输入的内容都给改掉了，采取一种全新的电梯外部输入方式，但是内部却没有变化，意思说也就更改外部内容的输入和安放就行
设计类图：
类图相比于之前倒是没有太大的变化，毕竟这次的要求主要是对于输入部分的细微更改。
写完代码参数分析：
拿到的最终版可以看到，其实这个代码算不上什么及其美好的代码，它的几个极端点都处于绿色安全界限之外，所以其实下次考虑的时候还是要多加注重安全阈值的大小。
思路讲解：
只需要处理外部列队输入的话只需要判断输入的起止点方向，作为一个分界来录入后期的DOWN和UP(方便后面的所有内容不需要更改)，然后就是把多余的内容塞到一个数组中，在所有内外列表输入完毕后把这个新数组与内部拼接就完成。
问题与解决：
1：在运行的时候发现在后续拼接会出现问题，直接接拼接会导致访问不当，比如无外部输入的时候会导致新列表为空
解决：直接开一个全新的数组作为载体承接原先旧的内部输入和新输入的内容并且以if判断前缀可行性。``
2：在运行的时候发现有答案错误。
解决：在与他人讨论或自己摸索实验样例下，发现有特殊样例测试异常，以为后续的检测更为严格导致测试点没有通过，现在更改后便可以了。
踩坑心得：
第一次的电梯调度问题，由于没有在提前设计好类图和流程内容的情况下直接就开始进行代码的编写，云里雾里，导致在编写题目的部分要求时改了又改。浪费了很多时间，还有就是没有提前理清楚电梯的运动模式，导致在运行代码的时候总显示答案错误，后期花费很多时间去更改。
第二次的电梯调度问题，也是没有细致考虑，程序中有直接对于空的访问，导致反复报错。不过也是在判断的时候对于&&和||判断的先后性没有细致理解清楚，但是也从侧面学会了一些稍微改变判断顺序便可不报错的方法。
第三次电梯调度问题，倒是没有太多麻烦的地方，也是得益于前两次的优化和更改，导致后续工作的高效。
改进建议 ：
相比较于c语言，java给我的感觉更加舒服，不论是idea的编写界面还是程序编写起来的舒适性，由于一个个的类与方法分明，我的逻辑被动变得比较清明。但是通过这次的大作业，也清晰认识到，事前设计的重要性，一个好的设计框架远比单纯的编写代码更加重要，以后要多加往这方面靠拢。养成良好的编写习惯。其次就是多加学习基本语法，并且学会灵活运用。在本次实验就是个明显的例子：
比如说把输入和操作和输出分成三个部分，一旦后期有要求进行了更改，就不需要大费周章地去更改一堆内容，只需要找到需要进行更改小区域进行截取更改，大大便利。还有就是利用正则表达式进行多个括号内容的控制，保证输入的内容绝对是符合要求的防止了例如《-1，Uo>等奇奇怪怪的内容被输入进去。还有就是直接进行判断返回数字，然后直接判断数字来进行电梯运动方式，这样一来万一后期在运动判断方面有更改也能第一时间直接改变返回的数字来快速更改电梯运动模式👌。
总结：
通过第一次的大作业算是直接极大助于自己的思维从c语言到JAVA的转化，加深了自己对于所谓的java“面向对象”的理解，现在敲起代码来也更加得心应手了。还有就是在第三次大作业中感受到良好设计带来的便利，从真正“实践”层次上使自己了解到设计框架的重要性。在学会强化自己编程能力的同时要学会借助团队和智能互联网的力量，学会融会贯通才能有长远的代码生涯发展。
然后就是建议教师别再静止提交系统的复制粘贴了，真正想作弊的人怎么防都防不住，反而太多的限制会导致正常人写作业的便捷性。
课程比较正常，但是作业的测试点太少了，不知道自己哪方面有问题，盲目地自己判断老师希望测试的点，会无故耽误很多时间😅。
其他方面倒是没有太大的问题👍👍👍。
浙公网安备 33010602011771号