OO第二阶段总结

（1）设计思想简介

OO第五次做业

　　三电梯调度做业中，第一次尝试了java多线程编程，对多线程控制的理解及其浅显，仅仅采用了synchronized和sleep的方法来避免多线程的冲突。即电梯每100ms扫描一次状态，调度器每100ms分一次任务，而且用sleep把二者错开来防止冲突产生。可是因为运算自己消耗时间，在超大数据的测试下，二者会渐渐交合，仍是会出现问题。

OO第六次做业

　　IFTTT文件监视做业中，对多线程的认知有所加深，使用了锁代码块的方法来防止进程不安全的问题产生。同时也重写了file类，来确保进一步的线程安全。

OO第七次做业

　　第一次打车做业中，进程不安全的状况较少，处理起来较为容易，经过整合调度器，即每一个周期扫描一次调度队列，而非每一个请求单独一个线程，有效地避免了冲突。

（2）基于度量分析代码

OO第五次做业

类设计以下：

事实上电梯逻辑原本很简单，即每个请求进入队列后，由分配器分配给电梯，若是是电梯内请求，就直接点亮电梯内的按钮。若是是楼层请求，就按优先级将按钮点亮并记录由哪台电梯来相应，即FloorButton类中elvId这一属性。这也变相地为每台电梯就构造了一个请求队列。而电梯本身运转的方法和以往的做业同样。可是考虑到输出的问题，每一个电梯还须要记录本身请求的详细信息，为了知足要求，这里直接将request的序号记录在了button类中，实属不智。

可是，在度量层次上却出现了极大的问题。

能够看到，在圈复杂度和嵌套块深度上电梯类均出现了过于复杂的状况。没错，在以前的做业中，调度器负责告诉电梯干什么，电梯只须要向哪走就行。而本次做业，调度器负责的是把任务分给电梯，但电梯本身还须要判断先执行哪一个后执行哪一个，至关于集成了以前做业的Scheduler，在实现上，因为scheduler的任务和电梯是彻底同时的，因此设计成了一个类，一个线程，却在度量上出现了大问题。

 

OO第六次做业

类图设计

本次做业采用了每一个触发器一个线程的思路，可是在实现上为了统一出现了一些不明智。

因为path-changed的存在，当其检视对象为文件时，须要检视文件的父目录，当我在线程中扫描本文件消失时，便会扫描文件父目录下的全部目录以检查文件移到的位置，可是我将renamed也设计成了同样的逻辑，只不过一个是限定，必定不在父目录下，且名字同样。一个限定必定在父目录下且名字不同。可是扫描时使用了相同的遍历方法。这致使了一些bug的出现。

圈复杂度始终是没法逾越的难关，因为输入的不肯定性，对输入的判断每每伴随着不少ifelse，本次做业光合法就有10种状况。。。这便致使了main中对输入的处理的复杂度太高。。。

 

OO第七次做业

 

圈复杂度几乎是没有问题，可是嵌套块深度过大，通过一番查询，发如今调度过程当中首先扫描了队列中的请求，每一个请求又扫描了全部的出租车是否符合条件，当抢单窗口关闭时，又要扫描全部的符合条件的出租车来肯定派单给谁，三层大循环加上无数的逻辑判断致使代码块过深。

（3）bug分析

OO第五次做业

第五次做业出现了一个bug，出现了在某些及其稀少的状态下请求丢失的现象。

但调试信息却显示请求被正确地分配给了电梯，且电梯正确地接收到了指令，但却没有执行。

测试他人bug的时候发现了对方在实现中出现了当电梯都被占用时，新进入的指令不会被分配给符合条件的电梯的状况，大概是判断逻辑中对比部分出现了失误。

OO第六次做业

第六次做业出现了当父目录过深，扫描所需时间过长致使测试线程的下一步操做已经进行，致使recover失败的状况。应该使用更安全的线程控制，而非单纯地sleep，扫描结束以后才交锁可能比较好。

测试他人bug时发现了一些sizechanged时不触发modified的状况。

OO第七次做业

第七次做业并无被测试出bug

第七次做业并无测试出对方的bug

（4）总结

总的来讲，对多线程的认知是愈来愈深，又学了os，对同步控制也不只仅是synchronized这么简单，在写代码时也思考了不少关于面向对象思想和多线程控制方面的方法，确实是收益颇多。基于度量来看，总有一些代码的状况分类过多，致使逻辑复杂度较高。可是在当前情景下，我已经尽可能地分配了职责，彷佛有些类的职责确实复杂，有的类就是比较简单。。