标签：OO 总结 请求 作业 调度 横向 电梯 bug 单元
第二单元总结
第五次作业
代码架构:生产者模型
-
单独一个线程InputHandler用来接收输入数据.
-
设立共用调度器Controller用来作为缓冲区对数据进行操作.
-
电梯elevator作为消费者模型用来向调度器发出指令处理数据.
调度算法:半优化ALS算法
即不仅携带与主请求目的地同方向的乘客,且携带能够在接主请求途中完成到达请求的乘客
类图:
bug修复:
本次作业未发现bug.
第六次作业
代码架构变化
-
由于本次作业新增了横向电梯以及会出现增加电梯的请求,所以对Controller进行了改动
-
按理说应该使用工厂模式将横向电梯和竖向电梯分开,但为了防止一些隐藏的bug,所以我将两类电梯通过type分开在elevator的方法类重定义了两类电梯的运行方式.
调度算法:自由竞争
即一起去接主请求谁先接到主请求则主请求归谁
类图:
bug修复:
修复了横向电梯由于休眠后接人未更换主请求导致电梯无方向把人锁在电梯里的bug.
第七次作业
代码架构变化
1.新主楼增加一个int数组用来储存哪一层拥有横向电梯.
2.人员下电梯时检测是否到达目的地,未到达则更新人员信息添加回新主楼中等待下一次运送.
3.判断停止条件更新为新主楼为空且所有电梯为空
4.canOut和canBring的判断条件有所更改
5.调度器的Canchange利用了elevator的容器遍历读取哪个电梯可以完成运送任务来调度电梯
调度算法:自由竞争
即一起去接主请求谁先接到主请求则主请求归谁,调度算法未发生变化
类图:
bug修复:
互测时修复了可自定义横向电梯因为获取新人后未更新主请求的bug.
UML协作图:
心得体会
多线程单元其实主要需要考虑的是线程之间的冲突问题,所以在第一次作业框架基本已经固定的情况下其实每一周的迭代工作并没有多累,基本上只是在原有的基础上增添十几二十行代码就足够通过新的测试,但是因为自己偷懒所有没有按照工厂模式将横向与竖向电梯分开的缘故,还是产生了一些我认为没有bug但是实际上会出现bug的情况,偷懒一时爽,互测火葬场,多线程的开发思路比写要更重要,没思路的时候一行都写不出来,但是突然有一瞬间你想到怎么做合适,就可以一次写很久,所以不需要和代码死磕,可能灵感就来源于一瞬间,紧绷的时候适当放松一下就会突然迸发灵感.
标签：OO,总结,请求,作业,调度,横向,电梯,bug,单元 来源： https://www.cnblogs.com/BUAA-Heimerdinger/p/16217317.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。