标签：OO 总结 请求 乘客 程序 队列 电梯 bug 单元

OO第二单元总结

架构设计

  三次作业中我逐步形成了如下的架构设计：

运行策略

电梯运行策略为ALS策略，即确定主请求后再考虑捎带请求。
RequestQueue的子类中把请求分为已分配的请求和未分配的请求。当电梯发出分配请求时，会根据电梯当前状态（运动方向、所在楼层、所在楼座）以及等待队列中乘客的具体要求来分配最合适的主请求。在电梯运行到每一处时，都会询问当前所在地是否可以捎带乘客。
下图即为纵向电梯在运行时的行为

电梯路径设计

在Controller中记录了电梯系统中所有电梯的可达信息。对于同一楼层存在多种可达性电梯的情况，我设计了SwitchBit这个类以便于进行判断。

路径决策如下图

若乘客不需要穿梭楼座，则直接将其放入相对应的纵向等待队列；否则向上下方向开始检索符合要求的楼层，若当前所在层就存在可达电梯，则放入当层的横向队列，否则放入纵向队列。再放入队列之前，还需要做的就是设置好中转地，当乘客到达中转地时，离开电梯并再次通过Controller进行路径决策。在这种方式下，乘客最多需要换乘两次来到达目的地。

架构分析

  使用工厂模式来“生产”电梯，使得架构有很强的可扩展性，可以实现诸多扩展功能如设计复杂路径、设置乘客优先级等。

类的协作

时序图如下

测试

编写了自动测试程序，记录每一次的输入输出以及保留测试日志。

  在这三次作业的强测与互测中，我的作业都没有被找出bug（当然没有被测出bug不意味着程序完全没有bug）

程序bug

在第三次作业的本地测试时发现了较多bug，如电梯在不可达楼座开门，乘客未全部到达目的地时程序就已结束等。通过简短的debug就解决了问题，在互测、公测中均未出现bug。

心得体会

  多线程程序不仅仅要考虑程序的正确性，还要兼顾时间、空间性能。测试的时候，不能只看输出的正确性，还要正确的评估程序运行的时间、cpu时间，只有把这些都考虑好了，才能算是把这个多线程程序做好了。

标签：OO,总结,请求,乘客,程序,队列,电梯,bug,单元
来源： https://www.cnblogs.com/Xayah06/p/16215759.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。