pta三次电梯调度程序习题总结

--------------------------------------------------------------------------------前言----------------------------------------------------------------------------

一.题目涉及的知识点有
1.数据结构：需要合理使用队列结构来管理电梯的内外部请求，确保请求按照正确的顺序被处理。
2.面向对象编程：需要设计合理的类结构，包括电梯类、请求类等，体现面向对象的封装、继承和多态特性。
3.字符串处理：需要解析各种输入格式，包括内部请求、外部请求以及结束标志。
4.数组运用：需要利用数组来存储和管理请求数据，进行查找和排序操作。
5.数据异常处理：需要考虑各种边界情况和异常输入，以保证程序可以正确运行
二.虽然题目量较多，包含三个逐步迭代的电梯调度问题，但只要合理规划时间，分阶段完成是完全可行的
三.难度属于中上水平，题目给出了提示以及类的设计参考图，只要认真阅读题目的提示以及参考图还是可以写出来的。

--------------------------------------------------------------------------------设计与分析---------------------------------------------------------------------
1.对电梯调度算法的分析
前两次题目的电梯运行规则如下：电梯默认停留在1层，状态为静止，当有乘客对电梯发起请求时（各楼层电梯外部乘客按下上行或者下行按钮或者电梯内部乘客按下想要到达的楼层数字按钮），电梯开始移动，当电梯向某个方向移动时，优先处理同方向的请求，当同方向的请求均被处理完毕然后再处理相反方向的请求。电梯运行过程中的状态包括停止、移动中、开门、关门等状态。当电梯停止时，如果有新的请求，就根据请求的方向或位置决定移动方向。电梯在运行到某一楼层时，检查当前是否有请求（访问电梯内请求队列和电梯外请求队列），然后据此决定移动方向。每次移动一个楼层，检查是否有需要停靠的请求，如果有，则开门，处理该楼层的请求，然后关门继续移动。
输入的数据如下
电梯内乘客请求格式：<楼层数>
电梯外乘客请求格式：<乘客所在楼层数,乘梯方向>，其中，乘梯方向用UP代表上行，用DOWN代表下行（UP、DOWN必须大写）。
当输入“end”时代表输入结束（end不区分大小写）
前两次题目都是根据输入将请求分为两个队列：外部请求队列和内部请求队列
然后在根据队列的队首目标进行分析，如果执行就消去队首数据，然后进行下一次执行，
根据此逻辑可以通过设计一个循环然后内部再设计多个if语句分别对应不同的情况即可以模拟电梯的运行过程.
第三次作业电梯的运行逻辑如下：
电梯运行规则与前阶段相同，但有如下变动情况：
乘客请求输入变动情况：外部请求由之前的<请求楼层数,请求方向>修改为<请求源楼层，请求目的楼层>
对于外部请求，当电梯处理该请求之后（该请求出队），要将<请求源楼层，请求目的楼层>中的请求目的楼层加入到请求内部队列(加到队尾）
这次的变化导致算法需要根据外部请求的楼层进行分析从而判断是up还是down的请求然后再套用前两次的算法逻辑进行代码设计迭代

2.代码的设计
第一次设计
根据源码分析图可以知道第一次设计
方法复杂度较高：最大复杂度达到 39 ，说明我的代码不够简洁，维护的难度较高，可读性低
代码块深度大：最大代码块深度为 7 ，说明代码有多处嵌套，比较复杂
注释占比低：含注释行的占比仅 4.6% 。较少的注释让代码可读性变差，其他人接手时，难以快速理解代码逻辑和功能意图。
类和方法数量较多。
根据类图可知，代码只设计了一个lift类，不利于阅读与维护
改进计划：
1.增加代码注释
2.提高自己的算法能力，以达到可以设计更简单的代码的地步
3。编程时尽量采用多类设计
第一次源码分析图如下

第一次类图如下

第二次设计
根据第二次源码的分析图可以看出第二次代码仍然存在第一次代码的大部分问题
注释过少：注释行占比仅 4.2% 。这导致代码可读性较差，别人无法理解代码
类内方法过多，平均每个类有 15.50 个方法导致类的可维护性较差
代码嵌套语句过多，最大代码块深度为 6 ，最深代码块在 207 行，导致代码可维护性差并且难以理解
依旧需要改进
根据类图可以看出，第二次代码进行了多类设计，但是依旧有缺点：类的设计不够好，导致维护依旧不是很方便
改进计划：
1.依旧是需要提高自己设计算法的能力
2.需要对类的设计进行理解与训练
3.需要提高自己代码在极端环境下的适应性，比如临界条件
第二次源码分析图如下

第二次类图如下

第三次设计
根据第三次代码的分析图可以看出
代码依旧存在以下问题
注释占比极低，注释行占比仅 3.6%
代码逻辑结构复杂，平均每个类有 15.50 个方法，不利于维护与阅读
通过类图可以看出第三次代码加入了乘客类（Passenger），取消了乘客请求类虽然提高的代码的可维护性但是依旧还有不足，应该还能继续进行优化
改进方案：
1.后续学习中继续学习面向对象的知识，提高自己的编程能力
2.规范代码书写，尽量写上注释
第三次源码分析图如下

第三次类图如下

----------------------------------------------------------------------------踩坑心得-------------------------------------------------------------------------
踩坑点1.在设计第一次电梯的调度程序时，并没有清楚的了解电梯调度程序的运行逻辑，一直以为是同时处理内部和外部所有数据后在进行电梯的运行，但是真正的算法应该是先处理两个队伍队首的数据然后再根据处理结果进行运行，即边处理数据边运行电梯，对题目要求的不理解导致我在设计算法时浪费了大量的时间并且一度怀疑是自己的设计有误，后面在询问了舍友以后才知道我其实是对题目的理解有问题，再对算法进行修改后，最后才成功通过pta的测试

以下为不理解算法时的提交图

以下为理解算法后的提交图

踩坑点2.在写第三次的题目时，由于输入的改变，导致需要判断外部请求队列的方向为up还是down
我一开始的判断方法有误，将<请求源楼层，请求目的楼层>中的请求目的楼层与当前楼层进行比较，但正确的方法其实是将请求源楼层与请求目的楼层进行比较，这就导致我的算法出现了问题

踩坑点3.在我解决了踩坑点2的问题后我发现我提交的答案依旧是错误的，经过对算法进行解析，我了解到我的方法run（电梯的运行方法）中少考虑了某些特殊情况，即请求源楼层与电梯内部请求楼层相同的情况这导致了我的代码出现了错误后面对这些情况进行了补全才解决

心得： 1.别一上来就敲代码，用笔记或流程图把电梯处理请求的步骤画清楚（比如 “请求先排队→逐个处理队首→更新电梯状态”），想明白每一步再写代码，能少走 90% 的弯路。
2.在些代码时要弄清楚本质的逻辑，比如题目中的：判断外部请求是上行还是下行时，只需要看 “用户从哪层来，想去哪层”（比如 3 楼去 5 楼就是上行，和电梯现在在几楼没关系），这才是最本质的逻辑。
3.写完代码后，可以输入一些特殊的情况（比如起点和终点相同、负数楼层、空请求），看看程序会不会出错。很多 bug 就在这些情况里面。
--------------------------------------------------------------------------------改进建议---------------------------------------------------------------------
以下是我对题目的编码改进给出自己的建议，做到可持续改进
1.类的设计必须遵循单一变量原则，从而达到可以根据要求来对类进行删改
2.方法设计要有前瞻性，类中设计的方法不要拘泥与用户的需求，不要抱着只要可以满足当前的需求就可以了的心态来设计方法，方法的设计要考虑的情况要更加广泛，适应多变的情况，这样在用户的要求改变时，我就可以对代码做出改进
3.我可以对代码进行模块化设计：将代码拆分成多个独立的模块，每个模块负责单一的功能。这样可以提高代码的可维护性和可测试性。
4.主动开展代码互测与设计讨论，和同学进行讨论，互相根据自己的代码设计测试样例然后用自己设计的程序运行，看看相互之间运行的结果是不是相同的，从而找出自己在代码设计中的缺陷
--------------------------------------------------------------------------------总结--------------------------------------------------------------------------
在写了这三个题目以后，我了解到了我在以后的学习需要：
1.在以后的学习过程中精进自己的算法
2.规范书写代码，例如类的命名，变量的命名还有注释的书写
3.在进行编程之前先好好了解用户的需求，而不是直接开始写代码，在充分理解要求后并且设计好类之后再进行编写
对于作业的改进建议：
在pta的题目中可以增加测试样例，把可能遇到的特殊情况或者容易错的情况的测试样例给出来，这样更有利于对于自己代码的错误排查