OO学习总结

Posted 2020-11-01 9998-0804

第五次作业：多线程电梯

多线程的同步和控制

1. 在本次作业里，请求发生器不断往请求队列里加入电梯请求，主调度器不停将电梯请求分发给从调度器，从调度器不断读取请求来操控电梯运行，因而这三者之间存在同步关系。
2. 请求发生器和主调度器之间共享了主请求队列，因而需要对主请求队列的加入、删除和读取方法均作同步，对此我采取的方法是在调用者的调用代码里加入synchronized代码块。
3. 主调度器和从调度器之间共享了电梯和从请求队列，在获取电梯的方法里我采用的对方法作synchronized同步，对请求队列的同步采用的与2相同的方法。

OO度量

类图

类图展示出了各个类之间的引用，共享关系。缺点是类图太过繁杂，引用关系较为混乱。

sequence diagram

设计角度

这次作业感觉严重违反了显示表达原则。 体现在各个常量都直接用的数字表示，没有用类的静态变量。 如果以后需求发生变化， 比如楼层高度更改， 电梯个数更改， 就需要修改所有的代码。 对Single Responsibility Principle运用得稍好一些， 主调度器就负责分派请求， 从调度器负责从自己的从队列里拿出请求操控电梯运行。 主调度器与请求发生器之间就是消费者与生产者的关系， 从调度器与主调度器又形成了消费者与生产者关系。

bug分析

公测有一个测试点挂了，互测有一个测试点挂了。都是同一个原因导致的： 拿到请求之后直接先去除了可捎带的和同质的再将剩余的请求分发。 这样做的问题在于， 假如电梯1在前往20楼， 扫描新进来的请求有去19楼的， 则我的程序会先把去19楼的请求分配给电梯1，再去看分配的不可捎带非同质的请求。 假如之后的一个请求是电梯2去20楼且电梯2的运动量小，则之前去19楼的请求应该分配给电梯2。
互测的时候我找到了很多对方的bug，本着和谐6系的原则没有报。。对方的问题在于代码逻辑太过复杂， 层层嵌套很多没有考虑到的漏洞。 随便多输入几条请求就会产生bug。

第六次作业：IFTTT文件监控器

多线程的同步和控制

本次作业主要的竞争出现在summary和detail文件的写入上。我采取的对summary和detail的写入方法都加锁，这样就能实现不同线程的互斥访问了。

OO度量

类图

我觉得写这次作业的思路还是很清晰的。通过读取监控命令来开启不同的监控线程，各个监控线程不断扫描文件夹查看是否有文件被修改，若有则通过Summary和Detail类来记录信息。

sequence diagram

设计角度

这次设计遵循了重用原则，将四种监视器的共性数据比如快照，summary和detail记录器等写到了父类Monitor里， 四种监视器继承了父类Monitor，再通过自己的需求来重写检测代码。但是对Single Responsibility Principle遵循得不好，比如InputHandler本该只产生请求， 却又产生了监视器线程， 这部分原则应由主线程承担。

bug分析

本次作业公测互测均未被找出bug。我拿到的测试代码风格很差， 各个类之间交替引用， 很明显会造成一边读一边写的情况。 由于代码可读性较差， 我直接根据readme进行黑盒测试。 根据bug树构造不同的测试样例， 我觉得最容易出问题的就是将recover任务和renamed, path-changed结合起来监控， 容易出现时序问题。 果然对方在这里挂了两个点。

第七次作业：出租车系统

多线程的同步和控制

此次作业的竞争出现在

1. 调度器派单<-->请求模拟器要加入请求
   

2. 调度器访问出租车状态<-->出租车改变自身状态
   对于1, 我使用了LinkedBlockedList阻塞队列来避免竞争问题，对于2，我选择了将访问出租车状态、改出租车状态的方法都加锁的方法。

   OO度量

   

   类图

   

   sequence diagram

   

   设计角度

   这次作业的课程上讲了SOLID设计原则，还讲了另外12个工程上要注意的设计原则，在测试过程中也会对设计原则进行考量。因此写这次作业比前两次更加注意自己的代码风格。
   Single Resposibility Principle和责任均衡分配原则: 地图负责提供路线， 出租车负责根据路线前进， 调度器负责读取出租车信息分配请求， InputHandler负责读取输入。
   层次化抽象原则： 将整个问题抽象为出租车类， 乘客类， 乘客队列类， 地图类， 调度器类。
   显示表达原则： 所有的常量替换成类的静态变量。尽量少采用数组直接存取信息， 比如出租车的信息，本可以用一个数组来保存其位置、状态、id、credit， 虽然方便，但数组下标容易混乱。所以用一个CarInfo类来保存信息， 每次访问出租车的信息时， 出租车都根据自己当前的状态返回一个CarInfo类。

   bug分析

   本次作业公测未发现bug， 互测发现一个bug： 出租车抢单时间和前往乘客目的地的时间不对。 导致这个问题的原因是系统时间和出租车系统的假时间总会有一定误差， 我输出的抢单时间采用的系统真实时间， 而前往乘客目的地的时间又用的出租车系统的假时间，因此在理论上这两个时间相差过大。将出租车抢单时间改为请求发出时间+3s即可。
   测试对方代码时，我发现对方的代码里居然有。。指导书根本没出现的内容。而且根据其代码来看应该是本次作业的后续作业。。显然对方要么是有预见未来的超能力，要么是抄的往届代码。。本来遇到这种情况也没什么可说的了，其代码风格也极烂， 一个文件里有多个毫无关系的类。。类的命名也毫无逻辑，读起来实在伤神。我最后构造了大规模的请求进行轰炸，最后发现对方的出租车线程在某些情况下会停止运行。另一个bug是。。没有提交需求分析文档。。

   心得体会

   这三次作业完成起来都不轻松， 尤其是多线程出租车IFTTT。前者是第一次多线程作业，后者的指导书太天马行空。我觉得开始写作业之前一定要多分析，模拟各种可能的情况， 确定好框架和要采用的数据结构之后才动手写代码。否则很有可能写到一半发现设计有严重缺陷而不得不推倒重来。与同学的讨论也是极为重要的， 一方面指导书规定的东西有的繁杂，有的简略，可以互相检查是否理解到位；一方面作业本身有难度，多讨论会发现不同的设计思路， 有的问题也越辩越明， 对完成作业肯定是有不少帮助的。