五一假期喜迎OO第二次博客作业。第五次第六次第七次作业都是多线程，从第五次的懵懂，到第六次的仗着synchronized为所欲为，再到第七次的翻车，感觉自己不明白的地方还是太多了，听理论课总是很想睡觉。。就陷入不懂而自知然而还是不懂的循环中。
第五次作业
第五次作业是多线程电梯。因为之前的上帝视角电梯写的方法不够有俗世普适性，所以导致整个作业都重写了。在重写输入部分时忘记了判断一层向下地狱电梯和二十层向上火箭电梯，公测直接挂了两个点。我想的是用一个RequestQueue队列作为托盘，输入线程作为生产者，扫描线程作为消费者，将请求放入每个电梯的队列里。同步控制方面将所有对RequestQueue操作的方法、对电梯队列操作的方法全部设为synchronized。现在感觉不应该把每个电梯执行的指令放在电梯线程里面。
类图
Request线程为主线程，主线程作为读入线程，将请求加入RequestQueue中。而MultiScheduler继承了上一次的调度器，是一个不断扫描队列并分配给Lift的线程。Lift线程只要有要执行的请求就执行。
度量
可以看到电梯类run有些超标。这是因为当时还没养成run里尽量简洁的习惯，在run里进行了大量的判断。
时序图
设计原则自检
- 违背了OCP规则，我的继承机制只是一个空壳。这是因为第一次的调度器并没有什么用处，我的核心调度是由RequestQueue类实现的。导致第二次调度器按照第二次的电梯设计写的太细了，仅仅只能用在第二次作业上。
- 违背了DIP规则，高层次的模块需要依赖低层次的模块。
- 电梯状态上直接用字符串和int，没有使用字面可懂的枚举变量。
分析BUG
公测
我：我因为上述的超级电梯问题错了两个可以说是最简单的公测。（上课的时候算了算全系大概四个人错。。）还有一个错是电梯没有分配给运动量小的电梯。这个公测其实疑惑了非常久，我在自己电脑上复现了不下20次结果都很正确。但对方测了两次都是不正确的，因此我觉得就是我多线程的问题。（玄之又玄）
对方：十分完美。
互测
我互测别人的：拿到了一位超级巨佬的作业，代码风格非常好，枚举变量用的非常优美。并且任务划分的非常明确，有十多个不同功能的类，变量名也很直白，有的还用了四个单词233（为什么看大佬的代码和看自己的菜鸡代码 都一样的难读）但他和我一样也出现了多线程的问题，同样也是不分配给运动量小的电梯的问题，可能与睡眠时间控制有关系（直接3000）.
别人互测我：因为我直接暴力取整了，那位同学无法接受，于是给我报了一个incomplete，确实这是我的考虑不周。
第六次作业
第六次作业IFTTT，本以为多线程电梯已经很难了，没想到这个更难。于是这个熬夜到很晚才写完，所幸写完没有大问题。
类图
这次我的实现又有那么一丝面向过程的味道了。。因为花了很多时间理解指导书，以及想清楚自己如何去实现，确实是能力有限。主类完成输入合法性的检测以及根据输入请求来启动Monitor。每个Monitor线程将对下属的所有文件进行间隔100ms的扫描，每次扫描生成一个SnapShot，比较SnapShot的差异并触发不同的触发器，完成不同的Task。因为实现问题Summary是线程而Detail是一个普通类。
度量
主线程也负责输入，在检测输入合法性的时候用了几个平行的if，感觉还是把输入单列出来，多用几个方法对不同的输入部分进行判断比较好。
时序图
设计原则自检
- 显然违背了SIP原则，Monitor类做了太多的事情。
- 对四种类型的Monitor，都是有共同点和不同点的，完全可以抽象成一个父类和四个子类，这样层次结构更加清晰，也遵从OCP、LSP原则。
分析Bug
公测
对方：他因为wait synchronized都加了导致了死锁，使得文件前一次的信息被覆盖。因此错了公测。
互测
对方：同样的原因使得他会出现两次renamed，无法捕捉到中间名的情况。还因为modified监控器写的不对的原因导致所有的含此监控器的都会出错。另有一些很奇怪的情况我也不知道为什么……
第七次作业
这三次作业真是递增式熬夜。（谁叫我太爱玩了，玩完又生病废掉一整天呢）这次作业开启了出租车时代，也是当下的一个热点。本来学长学姐们异口同声说很简单，再加上看完指导书感觉任务很明确，我就信了！！我以为就是很简单！！（大佬的话不可轻信）结果这次是写的最差的一次，被报Bug最多的一次。
类图
Main会先调用ReadMap类实现对地图的读入，再生成100个出租车对象并随机生成他们的初始位置。之后启动出租车线程，启动Controller，启动乘客线程等待输入乘客请求。在出租车线程中每辆出租车将根据自身状态不断运动。Controller不停拿出RequestQueue中的乘客并将之分配。乘客线程则是不断地等候输入，并生成一位乘客加入RequestQueue类。
度量
Gui方法的就按下不表，read方法因为循环多层，多层判断使得嵌套深度过多。在输入方面还是要下功夫啊。
时序图
设计原则自检
感觉这一次设计原则方面还算好,大概是没有机会让我违背原则:)
分析BUG
公测
对方：这位小可爱忘记了判断相同请求。
互测
我：这次真的做的太糟糕了。因为时间问题以及我的脑子转不过来问题，对于gui给的DSP我没有充分优化，使得每次开始都初始化了一次，占用了时间，导致了一个错误。另一个错出在同步控制方面，我猜想还是因为sleep时间的问题。因为这在第五次作业中也出现过，我认为我的synchronized没有问题，应该是我直接sleep(exact ms)加上假时间一起出的问题。
对方：对方写的很好，唯一的不好就是输出上让测验者看的很艰险。他有一个输出时间上的问题，私以为是计算拖后了系统时间，而他又采取的真时间的方法导致的。
总结
多线程
- 感觉导致我多个错误的原因都是没有采取正确的sleep 时间。应当在计算前set一下时间，睡眠时要去除计算所用的时间。
- 话说只用synchronized和sleep是不是就够了？我只会用这两个，从没有用过Wait notify……
- 在写多线程之前一定要想清楚几个线程、线程之间的交互对象、怎样保证线程安全，将共享状态和线程分离开。
设计
- 我会到周一在纸上设计好我的类，我的方法，我的调用。但是我的设计总是太“浅”了，没有进一步去想怎么把它变得更分工明确、更易维护、更加抽象。下次应该多想想如何在已有的基础上改善。
- 还有一个不足之处在于：我喜欢全部写完以后再测试。在前几次作业中我这么做都很顺利，但第七次出租车中我找了很久，一个一个类找才找到我的出租车为何木讷在原地（手动再见）。以后应该写完一个模块对这个模块debug。
心态
这几次心态真的变了，上一次互测直接抱着祝对面五一快乐的心态了。但还是不想就此放弃吧，所以没有放弃作业，通宵我也要写完。希望以后的作业我能够早一点开始，周末少玩一点。OO还是学到了很多的东西，很大地训练了自己的代码能力。
感谢舍友一起讨论，感谢帮我度量的ybw和提供机器的组长