第五次作业：多线程电梯
之前早就听说这次作业比较难，而且因为某些原因我开始的比较晚，导致很难按时完成作业，经过权衡，我放弃了这次作业。
第六次作业：文件监控
1、设计思路
和其他人的普遍认知一样，我也觉得这次作业不是很难。于是，我没有经过认真思考就开始写，写到一半之后，我才发现自己的代码构造有问题，但是这时候重构之前的代码又要花费大量时间，于是我干脆没有改前面的代码。结果，当我写完这次作业之后，我发现自己的代码写得非常丑，因为代码中的冗余部分占了至少三分之一。
我的设计思路还是很符合指导书的，主要就是构造和比对监控范围的切片，根据要求输出变化。我还按照指导书编写了线程安全的文件类SafeFile，一开始，我给这个类定义了一个File类属性，然后定义了一些带有synchronize关键字的方法来实现文件操作。但是后来在构建代码的过程中我越来越觉得这个File类的属性没有太大用处，于是我去掉了这个属性。后来经过同学的介绍，我发现完全可以把SafeFile类中的方法全部写成静态方法，这样的话既省去了实例化对象的步骤又最高程度地保证了线程安全，可谓一举两得。
2、度量化分析
仅从上图的Total Lines of Code一项就可以看出我的代码写得有多丑，因为我用了别人两倍的代码行数。究其原因，其实是我把监控文件和监控文件夹两个功能分开了，然后又把renamed等四个功能又分开了，这就导致我的代码有八个包含大量重复代码的独立的类，其实他们完全可以合并成一个或两个类。
3、类图
4、bug分析
本次作业无论是公测还是互测我都没有被发现bug，可以说是很幸运了。其实这也在意料之中，因为我在自己测试的时候就很难发现bug，而且我的SafeFile类写得非常线程安全。
我分配到的那个测试代码没有线程安全类的bug，但有一个结构上的错误，例如当我监控test文件夹下的a.txt文件的renamed时，如果test文件夹下的一个子文件夹内已经包含一个与a.txt完全相同（可以理解为复制过去）的文件，那么他的程序会把这两个完全相同的a.txt识别为一个path-changed变化并输出（也就是说无视了输入的renamed监控，这让我感到非常奇怪）。估计是由于相同的问题，他的公测有四个点过不了。我翻看了他的代码，发现他写得比较简洁，至少比我写得简洁多了，但是出现这样严重的错误实在很可惜。
第七次作业：出租车1
1、设计思路
虽然我没有写第五次作业，但我还是构思了的，我觉得这两次作业的思路非常相似。Map类负责打开并读入并存储地图。InputHandler负责把控制台的输入转化成请求并把有效的请求输入到线程安全的请求队列中，SchedulerMaster负责过滤同质请求并且为每个请求创建Scheduler线程，Scheduler会创建WindowTime线程，3秒内记录抢单的出租车信息，3秒后，根据一系列标准选出派单的出租车，把订单信息告知Taxi类，然后Driver线程检测到Taxi类的属性变化，开始控制Taxi接乘客、送乘客。用上次作业编写的SafeFile类中的write方法完成写文件操作。
2、度量化分析
很遗憾，从上图可以看出我这次作业又写了一千多行，可以说又写得比较“冗余”了，其他部分好像也比较有问题，不是很面向对象，尽管我已经比较努力地在写了。
3、类图
4、bug分析
这次作业我又没有被找出bug，可以说是非常幸运了，但是文档等级是一般，因此在以后的作业中还是要更认真地写。其实我的代码有一个问题，不知道为什么，我的代码在运行的时候，时不时会导致gui类报错：地图不是连通的！然后退出程序。这让我感到疑惑不解，因为讲道理我写的代码不会影响gui的算法，但是他的算法居然能让边界点到某一点的距离为MAX，然后报地图不是连通的错，实在是让人匪夷所思。后来我把他的报错和结束程序部分的代码注释掉，这下就可以完美运行了。总的来说可以说是很迷了。
这次我分配到的那个代码又是十分的干净整洁，文档也写得很不错，只是一百辆出租车输出到一百个文档里让我测起来很吃力。我用了很多方法都测不出bug，可以说这是一份非常优秀的作业了。
心得体会
通过这两次作业，我对线程安全的编程方法有了一定的了解，也在同学的帮助之下学会了使用静态方法来解决线程安全问题。设计原则方面我越来越注重面向对象，像前三次作业那样几百行的方法几乎已经没有了，开始变得“比较高内聚，比较低耦合”。最后希望第七次作业是后面一系列出租车作业的一个良好的开始，也希望我今后通过学习能对面向对象编程有更深入的理解。