OO第5-7次作业总结
三次作业多线程设计
第五次作业多线程电梯的设计为:输入、总调度器、三部电梯,共5个线程。输入和总调度器从共享对象——请求队列——中获取请求,由总调度器向三部电梯系统派发请求,一个电梯系统本身就是继承的第三次作业的具有捎带功能的(拥有一部电梯的)调度器,可以自行处理派发到电梯系统的一系列请求。
第六次作业IFTTT的线程设计为:每个监控作业一个线程,相互之间没有交互。
第七次作业设计为:主线程、100辆出租车、每个请求一个线程。主线程调用输入处理方法每增加一个请求就开启一个请求处理线程,所有请求处理线程共享100辆出租车,可随时获取其状态。(感觉每个改成一个请求处理线程专门处理所有请求似乎更好一些,下次作业实现……)
第五次作业——多线程电梯
(这红红的三行……为什么我记得写的时候只有一行是红的……)
满减红的主要原因如下:
1.在输入处理的方法中因为要判断合法输入的问题,所以用到了不少if。主调度器中判断可捎带、FR请求分配有很多限制,导致大量的if条件判断
2.电梯系统和主调度器中有太多的属性,传入的参数过多。尤其是电梯系统,为了实现功能,不管不顾的加一些属性而不是方法内部的局部变量,来达到各方法内用到变量的统一性
优点:充分利用了上一次作业(具有捎带功能的调度器)
缺点:在线程类代码中直接进行访问控制,调度器拥有对所有对象的引用,把电梯对象当成一般对象进行访问(真的是每次总结都是典型反面教材……)
自己的bug:
1.本次作业是重构的(可以说是重写orz),着重点放在了之前捎带和电梯运动的设计上所以忽略的输入处理,readme和一部分也没有更新,导致不支持超过int范围的数字,输入楼层数超过int范围,程序直接crash(啊多么痛的领悟……)
2.readme写的比较仓促说了没有说电梯号不支持#和前导0,被抓住了小辫子
测试代码的bug:
1.电梯的时间受输入end的时间的影响
2.电梯在开关门状态时输入会多开一次门
3.捎带问题(时间久远真的记不清了……)
依旧是黑盒测试,菜鸡看代码看不懂啊orz
第六次作业——IFTTT
Detail类是从来记录detail任务的类,里面存入一段时间内触发detail任务对应作业的详细信息,由于没有整理成一条信息传入,而是分别四项前后的变换,所以……这个传入的参数非常多,红色就又出现了。
MoniterFile是监控文件的方法,由于里面触发触发器后的处理是三个任务一起写的,所以嵌套了好几层if,满减红就又出来了
这次作业有一点做的比较好就是每个类每个方法都各尽其职,但也没有包揽所有的任务。很多方法都抽象成很小的方法(比如各种对比快照的方法),代码看着比较清爽(几个触发器类里的MonitorFile方法除外)
踩坑小能手再次上线,本次踩中的坑有:
1.每个监控任务一个线程(这都不是老师说的一个目录一个监控线程的问题了,情况更为严重orz)
2.四个触发器四个类,其实里面的代码大同小异(可以用继承或者写成一个类,内部抽象)
自己的bug:无
测试代码的bug:
1.rename无法监控子目录下的文件
2.rename作业 被recover后,同目录其他作业保存的不会被触发、但也不会更新,导致detail被再次触发时,记录的变化是recover之前的信息到新信息
第七次作业——出租车
这个表是包括GUI的(所以有些锅我不背。。。)
每次复杂度红似乎都是因为InputHadler,下次作业要好好想想怎么办
ReqSche请求处理线程,传入的参数过多,因为有太多属性了,不知道要怎么改……
自己的bug:无
测试程序的bug:
1.没有指导书输出条目第三项的文件输出
2.出租车送乘客到目的地后信用度不加3
3.无法识别有空格的地图
这一次因为没有输出文件,迫不得已通读了对方代码,难能可贵的是居然看的差不多懂了???然后后两条是看代码的时候发现的bug。OO互测一来第一次通过代码分析别人的bug,不得不佩服自己的勇气。其他的问题恕我这个菜鸡实在是不能通过代码看出来了,毕竟没有文件输出,代码也不能随便改……
多线程之路的心得
多线程玄学,通过加锁似乎慢慢得有了好转,然而依旧是懵逼的,需要在作业中继续摸索
多线程不易,熬夜伤身,给大家递上护肝片