面向对象第八次作业

代码分析

第五次作业 多线程电梯

UML图和协作图

代码复杂度分析

这次作业的主要难点在于对于多线程的理解和实践，一方面由于老师上课讲的着急，内容也更多的偏向JVM的介绍，因此对于多线程编程的一些思路和方法没有多少了解，另一方面由于时间不足也没有时间去更详细的自学多线程，因此基本上只能依靠自己在敲代码的过程中和debug过程中的探索和对于其他人的代码中的多线程思想的借鉴来实施。

另一方面，由于之前几次的电梯都是模拟时间，从这次开始突然变成真实时间，因此以前所写的所有内容几乎都不可用，只有输入输出部分可以稍作修改，其余的控制等部分完全是依靠模拟时间的方法。如果之前就知道这次作业要用真实时间，之前几次作业即使可能会因为超时被报incomplete，我也不会使用模拟时间，一方面模拟时间对于同质和捎带请求无疑更难判断和处理，另一方面模拟时间对于本次作业基本没有帮助，同质和捎带的判断都要重新设计算法重新实现。

BUG

本次作业出现了两个bug

1. 不能复制多行输入，如果复制多行，只能读取第一行，但是如果先让读取控制台的Scanner sleep一段时间再开始，输入的多行数据都能被读入，而且输入时间相同。原因未知。
2. 理解错误，将每行指令数和指令行数的要求弄反

第六次作业

UML图和协作图

代码中涉及到的线程及其协作关系：

代码复杂度分析

在完成多线程电梯的任务后，对于多线程的编程有了进一步的了解，本次作业的主要难点在于对文件信息进行读写操作时的冲突问题，通过对SafeFile的类锁加以解决。

另一方面，由于IFTTT本身的难点以及作业指导书的不明确、多次修改，甚至还有多次的反复变更，很大程度上增加了完成作业的难度以及产生Bug的可能性，尤其是在已经完成编程开始debug时，一般都不会再关注issue的内容，因此不知道与之前的要求相冲突的地方，给别人报了不符合之前要求但是符合后来要求的bug，也给自己带来了bug。

BUG

1. 我不允许对已设立的文件/目录的任何子目录/父目录再建立任何监控，助教表示这个不行
2. 因为在更新文件快照的过程中，传参部分存在一些bug，影响了change-path后的recover操作和输出的文件信息
3. 作业指导书的冲突。最开始的作业指导书要求在文件消失后出发size-changed 到0KB的操作，但是最后的issue内容变成了不触发任何触发器。

第七次作业

UML图和协作图

涉及到的各线程和操作流程图：

代码复杂度分析

本次实现的出租车调度系统需要以下几个对象之间进行交互：

1. 乘客请求：发出请求，请求将被系统内开发的请求处理RequestHandler所捕获，然后针对每一个被捕获的请求，设立其对应的请求线程用于实际执行该指令
2. 请求线程：用于实际执行该指令，被请求处理模块建立，扫描指令发出地周围的出租车信息，判断那些出租车可以接单，那辆出租车最后将被派单；在该线程中，也将建立新的线程BFSThread用于获得图中各点到出发点和目的地点之间的距离信息
3. 地图：用于存储输入的地图信息和获取距离信息、判断连通等地图操作
4. 出租车：在没有被派单时随机移动，在被请求线程派单后，每次通过地图获得下一步运行的方向，知道到达目的地转入随机运动为止

因此，系统中主要包括以下四个主要的类：

1. RequestHandler：处理输入请求，判断请求合法性，开始请求的执行
2. RequestThread：每个请求的实际执行者
3. Map：管理地图信息，进行地图操作
4. Taxi：出租车

BUG

还在申诉中的bug：

时间增量：我是计算的系统时间而不是额外使用一个计数器存储时间，因此一定会有误差。有些人使用的是一个基础数值不断+200，我认为这个是假时间，而对面的测试者认为我输出的真实时间反而有问题

派单时刻：readme中有写，如果派单时出租车正处在两个位置点之间，即sleep 200ms时，将在醒来后开始处理派单。测试者认为需要立即处理派单。

寻找bug的策略

在寻找自己的bug的时候更多的靠的是编码前的设计和编码时的思考，还有在结束编码后的自行构造有针对性的测试。

在寻找别人的bug时，先大致的找到对方一些可能出现的bug，包括基础的功能、一些复杂情况下的测试、边缘测试还有作业指导书不断修改过程中前后并不完全一致的以及不明确的要求，然后利用自己构造程序、debug的过程中发现的一些易错点和较为复杂的测试点进行测试。

在发现一些问题后，大致阅读代码找出错误位置，思考是否存在其它有关联性的bug。

心得体会

1. 在正式开始编码之前充分设计、验证算法
2. 编码的过程中测试
3. 修改代码时考虑修改的影响
4. 构造前参考issue里面其他人的疑问
5. 不要纠结于边缘点。边缘点的情况毕竟是少数而且发生概率极低极低，另外由于多线程的执行情况不可预料，发现到可能的边缘点后稍微注意一些，不要过多关注即可。
6. 设立DEFINE类或者interface。java中没有C语言的#define，可以单独设立一个interface，其中定义一些常亮，在需要使用的类中将其实现即可。
7. 合理设计数据结构，适当利用LinkedList，LinkedBlockingQueue，HashMap等
8. 关注README修改，以防出现readme前后冲突的情况被测试者挖坑。