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