第五到七次作业总结

Posted 2020-11-02 jyqin1117

三次作业多线程设计

第五次作业多线程电梯的设计为：输入、总调度器、三部电梯，共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，不得不佩服自己的勇气。其他的问题恕我这个菜鸡实在是不能通过代码看出来了，毕竟没有文件输出，代码也不能随便改……

 

多线程之路的心得

多线程玄学，通过加锁似乎慢慢得有了好转，然而依旧是懵逼的，需要在作业中继续摸索

多线程不易，熬夜伤身，给大家递上护肝片