OO第二次博客作业
Posted I WANNA
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了OO第二次博客作业相关的知识,希望对你有一定的参考价值。
一、第五次作业——多线程电梯
(1)分析:
因为时间比较紧迫,所以采用了伪多线程的方式,即计算还是单线程,但是输出是三个多线程。不过最后被判无效了,GG。
现在分析一下觉得还是挺清晰的,电梯开三个线程,在分派任务的时候wait,notify一下就行了。
算法分析:
1.每个电梯有一个list队列,在新任务来的时候决定加入哪个list
2.有变动的list更新(用上一次的代码,从头算到尾,得到应该输出的真实时间)
3.三个线程死循环,遍历对应的list,如果有请求的应输出时间小于当前时间,输出,标记。
最麻烦的是关于路径的计算:从当前系统时间中找到电梯此时(输入待分配请求的时间)的主线程,计算自上次完成主请求后的路程(与数据结构有关,每个主请求确认之后都要更新楼层数组,记录应到达的时间,加入一个捎带就往“后”更新一遍楼层数组)。
(2)类图:
(3)体会:
还是没有摆脱能用算法解决的决不用划分对象解决的思想,觉得那样调试太麻烦了。不过通过之后的训练感觉慢慢接受了这种编程的思路,虽然有的时候仍然感觉划分对象写得跟函数没什么两样。
二、第六次作业——IFTTT
(1)分析
1.任务分析(细致+耐心):这是本次作业最麻烦的地方。首先是基本功能的实现,再者是对应关系的限制。
2.file的不安全性:封装
3.实时读状态和存快照的选择:考虑到目录量和文件量本次没有做限制,所以决定用实时读取的方式确定当前的状态,并在readme中阐述清楚。
4.怎么开线程的算法:考虑到120个线程有些多,想到了一种针对实例开线程的方法。每个路径都会有4个act的字符串数组,在线程的死循环中会首先把所有可能的tig触发都判断一遍,然后遍历各个act数组,如果满足tig的同时也满足某act的数组,则针对该tig相应对应的act。
(2)类图与时序图
(3)结果分析:
优点:线程数量比较少
缺点:加锁的方式比较暴力,所以一开始调死锁调了半天。慎用类锁加嵌套使用,同步的代码越短越好。
(4)体会:
读需求文档耐心很重要,需要自己把大段的文字整理成思维导图记录在纸上。分析同步的时候也应该现在纸上作分析,把类和线程相互的引用关系画出来,再决定锁的类型或范围会比较清楚。
三、第七次作业——出租车(1)
(1)分析:
1.线程安全:请求和出租车会涉及到互改状态,且会出现一对多和多对一的情况
策略:ask单方面改变taxi,taxi中与改变状态有关的方法使用锁。
2.时间:出租车的运行时间和请求的时间窗口都要求实时,所以要尽量缩短切换时间
策略:少开线程,把ask和taxi都用容器存起来,使用单独的线程循环容器以更新数据。
3.状态转移:出租车的状态机(需要细致读题)
4.算法方面:最短路径的选择
策略:使用GUI中的bfs存两点间最短路径长度。a到b的最短路径递归:与a连通的、与b为n-1的点c为路径上一点,a=c,n=n-1。
(2)类图与时序图
(3)结果分析:
1.bug:忘记处理file的不安全性了。其余bug正在讨论中。
2.优缺点分析:
优点:信息交互简单,分析冲突的时候比较清晰。借用了gui中的代码,减少了工作量。
缺点:知识盲区——单功能原则和类之间的平衡原则的分界线还不是很明确,导致被扣设计分(这两者是如何做到兼得的呢?);DIP原则后期没时间改了,但是这个原则是我最不能理解的,只能停留在要写抽象接口的层面。还有严格的卡时间和卡步数问题,不知道怎么处理。最短路径算法有些过于暴力,所以必须先存一下,避免每次启动程序要等10分钟的情况。
(4)体会
还是要实时关注讨论区和微信群,不能从确定架构开始就不看了,比如说这个的接客1s是进入stop状态。
读别人的代码仍有一定的困难,且花费的时间较长。
以上是关于OO第二次博客作业的主要内容,如果未能解决你的问题,请参考以下文章