oo第三次作业——项目的问题与反思

体会

“我饿了但是我没有胃口；我想死但是我没有心情”——《生活》

每一次oo都是对心境的历练。第三次尤为深刻。

回头来看，这次oo的结果是bug没有de完，因此这次的公测甚至之后的互测表现都很一般。结果并不是很好。当然，我们在问题分析上应当进行过程。此次写作业过程中有三大错误。以下分析仅针对自己的状态。三点分析后才是对于本次题目的分析。

（一）轻敌

在上次作业的分析中我曾经指出，在构建框架上花的时间远大于电梯逻辑的是实现细节。因此，在并没有上手写作业之前，我对这次作业的认识是构建电梯的核心。我觉得构建核心并不难。当然，这种思想让我之后吃尽了苦头。轻敌使我先做了os，在oo上下笔即晚，之后心境的剧烈波动可能也与此脱不了干系。

（二）构思

在周一我开始阅读指导书，当晚无课，我用整晚的时间都在进行项目的构思。这里我要详细说明一些事情。

在第二次作业中，我就花费大量时间进行作业的构思。当时隐隐约约这样子长时间思考并非正确方式，但由于后来思考下构建的类与类之间的关系较为清晰，并没有特别意识到这样的问题。但此次作业中我真真切切感受到了时！间！的！浪！费！是的，就是时间的浪费。在一整晚的思考中，我用一个小时架构出了大致的框架，或许是由于不自信和眼睛疼的原因，我试图构建出某些地方的细节，构思清楚后再下笔。但是，由于这次作业本身的逻辑就很复杂，不是简单的思考就能想清楚的。这样导向的结果也很显然——我的头晕了。在这种思路没有想清楚的情况下，我试图去换种方式，结果发现更加没有思路。这样一来二转，我之前想的又全忘了，又要重头再来。由此看来，作业的完成在构思清楚合适的框架之后便要下笔进行细节的琢磨。其中的时间比例尚需细细揣摩。

（三）心境

在第一次作业中我的心境就出现过较大的比较烦躁的波动，可能就是很简单的对于码代码的一种不自信吧。在第三次作业中，我的心态——崩溃了。在周二，我对于oo作业是厌烦的，厌烦到碰都不想碰的状态。在这种状态下，我勉勉强强写出了一个大致的结构。勉强的心境去码代码就会缺少一种创造的灵感。在具体的代码实现时会导致很多细节都完成地不好。到了晚上，我甚至有一种这次作业就算无效也就这样了的感觉，那种情况下，真的是对于码代码没有一点欲望。中间也一直再调整自己，但是效果并不是很好。再到第二天的中午，这种状态才好一些。能够重燃debug的激情，解决掉很多代码中的问题。这次心境的感悟就是在合适的时间做合适的事。当做的事就提前做。想做再去做，否则低效且无效！

带有ALS-schedule的调度策略的电梯运行系统分析

一、项目需求

 在进行项目设计之前我们要搞清楚项目需求，即便是简单的电梯设计也不例外。因此，我们首先来分析电梯运行系统的项目需求。

本次电梯作业在输入上基本继承于第二次作业，仅将原“第一条输入时刻T必须为0”修改为“第一条指令必须为(FR,1,UP,0)”。输出在格式上有较大变动，将原来的ERROR更改为INVALID[request]进行输出，同质请求也需要输出SAME，对于合法请求亦修改为[request]/(sth)输出。输入输出之后，重点是调度策略的改变，由原先的简单调度变为具备捎带功能的调度策略。接下来我们详细分析一下：

捎带请求理解：①从请求队列中获取主请求，判断该主请求可捎带的所有请求；②当主请求完成时，若仍有未完成捎带请求，则将按输入排序最先未完成的捎带请求升级为主请求，同时重新扫描队列，判断所有可捎带请求；若无则执行①。

主请求可捎带请求的时间范围：从主请求发出时刻起（包括发出时刻），到电梯到达主请求要求的目标楼层开门止（不包括门打开时刻和开门过程时间）。

可捎带请求需满足的条件：

①(e.sta = UP → 10>=e.n>e.e_n) || (e.sta = DOWN→1<=e.n<e.e_n)

电梯在运动状态且目标楼层在除本层外的相同方向上。

②(r.dir=e.sta) && ((r.dir=UP→(r.n <= e.n)&&(r.n>e.e_n)) || (r.dir=DOWN→(r.n>=e.n)&&(r.n<e.e_n)))

若请求为楼层请求，则请求方向需与电梯运行方向相同且请求楼层在电梯主请求目标楼层与电梯当前楼层之间（之间不包括电梯当前楼层）。

③(e.sta=UP→(10=>r.n > e.e_n)) || (e.sta=DOWN→(1<=r.n<e.e_n))

电梯内请求的目标楼层在电梯的前进方向上。

二、项目设计

（一）宏观思路

在确认完毕电梯的设计需求之后，我们接下来便对电梯进行设计。粗略来看我们有两种设计思路，其一为请求导向；其二为暴力模拟。

以请求为导向的设计思路便是在第一次作业的基础上，将其中schedule方法（获取队列中的请求）进行改造，使其完成能够每次弹出需执行的请求即可，其他方法不需要进行变化。目标简洁明了但难点在对schedule方法进行改造上，但如果不进行暴力模拟很难进行判断。

因此，主要的实现思路便是模拟电梯的运行，在电梯运行过程中进行可捎带请求的判断和主请求与捎带请求的转换。

（二）设计框架

具体的设计实现时据笔者了解主要有两种方式，一为构造标记数组对请求队列中的请求进行标记，二为构造新的主请求队列并对其进行维护。笔者采用的为方式二。

首先我们确定电梯的运行状态，电梯共有上下行，开关门，以及不动四种状态。构造方法每次时间移动0.5秒，进行电梯运动模拟。

主请求队列为空且电梯为非开关门状态时获取请求→遍历请求队列删除同质请求，获取可捎带请求→当前楼层队列输出→电梯响应

（三）设计实现

1、主请求队列维护

笔者在主请求队列维护时，逻辑上并没有完全模拟主请求队列，主请求完成后重新遍历的方法。笔者记录当前运动方向上最远的目标楼层，同时每层到达时对主请求队列按输入顺序维护。个人认为应该具有相同的效果。

2、同质请求的判断与删除

因为采用模拟运动的方法，所以同质请求的判断通过设立电梯与楼层的布尔类型的按钮数组进行判断。如果某请求在电梯未来一秒前对应的按钮是亮的，那么该请求即为同质请求。调用队列中的删除方法进行删除。值得一提的是，在进行同质请求判断时，判断是否同质的条件并不简单为是否灯亮，而是某请求的时间及其一秒后，其所对应的灯是否为亮。

3、可捎带请求获取

捎带请求判断基于上述三条准则进行判断即可。

4、楼层请求输出

分别在请求与电梯的构造请求的输出方法与电梯状态的输出方法即可。