OO第二单元多线程电梯总结

OO第二单元多线程电梯总结

第一次作业

设计思路

Input为输入线程,负责不断读取请求并将读到的请求放入调度器中。

Dispatcher为调度器,是Input线程和Elevator线程的共享对象,采用单例模式。Dispatcher中list为请求队列,over为输入线程结束的标志,当输入线程读到null时,将over设为true。

Elevator为电梯线程,采用傻瓜调度(FAFS)。

代码分析

SOLID原则分析

Input线程负责输入,elevator线程负责取指令执行的单一负责线程比较好地实现。

开放封闭原则不能满足,程序可扩展性较差,增加电梯数量或者实现更复杂的调度算法时需要进行很大的修改。

公测和互测

公测和互测过程中没有被发现bug,也没有发现别人的bug。

反思与总结

多线程第一次作业主要帮助自己理解多线程,没有过多考虑之后作业扩展的问题,程序的可扩展性较差。

 

第二次作业

设计思路

Input为输入线程,负责不断读取请求并将读到的请求放入调度器中。

Dispatcher为调度器,是Input线程和Elevator线程的共享对象,采用单例模式。Dispatcher中list为请求队列,over为输入线程结束的标志,当输入线程读到null时,将over设为true,elevator为电梯线程,在检查捎带时获取电梯状态。

Elevator为电梯线程,采用可稍带调度(ALS),电梯内部有自己的队列用来存放已经进入电梯还没有出电梯的请求,出电梯后将其从队列中移除。

代码分析

SOLID原则分析

单一负责原则,输入线程和电梯线程地分工和第一次作业基本相同,只是增加了电梯内部的捎带算法,总体上符合类功能的独立性。

开放封闭原则,相较于第一次作业,第二次作业中的电梯类可扩展性较强,如果不想优化实现,可以在此电梯类的基础上进行扩展。但是调度器类如果要实现多部电梯,则需要进行的修改比较大,可扩展性较差。

公测和互测

公测和互测是因为同一个问题出现了错误,如果电梯当前楼层不是主请求(电梯内请求列表中的第一个)的其实楼层,则电梯在移动到主请求的初始楼层的时候也可以进行捎带,举个例子:电梯当前楼层为1层,主请求为1-FROM-5-TO-3,则电梯在移动到5层的过程中请求2-FROM-2-TO-3可以被捎带。这种情况下,当所有捎带请求都已经执行完毕的时候,没有更新电梯的状态,即电梯应该向上运行还是向下运行,目标楼层应该是多少,若没有更新,则电梯列表非空且无法执行主请求,电梯会陷入死循环,造成CPU超时。

反思与总结

第二次作业需要实现可稍带调度(ALS),这部分算法主要在电梯中实现,引进了电梯当前所在楼层、运行方向、是否开门,主请求是否进入电梯等变量,在实现的过程中一些问题考虑不够全面,细节处理不是很好。第二次作业共写了三份代码,感觉结构设计得不是很好,线程之间的交互也做得不太优雅。

 

第三次作业

设计思路

Factor请求拆分后的因子,内部变量elevator用来表示这部分任务需要由哪部电梯来完成,id为用户的id,fromfloor为这部分任务的初始楼层,tofloor为这部分任务的目标楼层。

Request与输入请求一一对应,即将每个输入的请求重新解析为一个Request,内部变量 ArrayList<Factor> list用来存储此请求被拆分之后的因子。

Dispatcher为调度器,由输入线程和电梯线程共享,采取单例模式,内部变量有一个数组用来存放电梯的请求队列,over用来标志输入线程是否结束。

Input为输入线程,负责不断读取请求并将读到的请求放入调度器中。

List为请求队列,分为从某层向上和从某层向下两部分。

Elevator为电梯线程,采用可稍带调度(ALS),电梯内部有自己的队列用来存放已经进入电梯还没有出电梯的请求,出电梯后将其从队列中移除,基本设计思想与第二次比较相似,在一些地方做了一点改进。

代码分析

SOLID原则分析

单一负责原则,入线程和电梯线程沿用第一二次作业的分工模式,总体上符合类功能的独立性。

开放封闭性原则,经过完善第三次作业中电梯的可扩展性比第二次作业有增强,调度器中的不足指出在于电梯请求列表使用了List而不是Arraylist,可扩展性较差,电梯数目增加时需要修改调度器(当时为什么要选List不记得了......)。

公测和互测

公测和互测中出现了两个问题

(1) 如果电梯在某层开了门,则电梯需要sleep(stoptime)后关门,由于判断条件给的不对,所以出现了电梯开关门之间没有sleep(stoptime)的情况,测评反馈信息:Elevator (name) serves too fast at floor (n)。

(2) 此次三部电梯每部都有最大承载人数的限制,所以可能出现电梯在某层不能将可稍带的用户全部捎带的情况,所以不能在捎带遍历结束之后将这层的数组清空。程序出现的问题,判断从某层向下的捎带之后将该层向下的数组清空,导致有些请求没有被执行就被删除,测评反馈信息:Passenger (number) has not arrived at his/her target floor yet。

反思与总结

程序写完之后一定要自己构造相对全面的测试样例对程序进行测试,不能过分相信和依赖弱测和中测,也不能懒,否则就会出现因为智障问题而强测翻车的状况。

猜你喜欢

转载自www.cnblogs.com/suirui/p/10759824.html