终于，终于又到了写博客的一周。可以说这三周的作业相比前三周来说的确是翻车了，不过翻车当中也有进步，从多线程电梯的不知所措到最后出租车能够有条理的写程序，感觉自己在这三周作业当中学到的知识比前三次要多得多。
作业分析
多线程电梯
度量
类图
时序图
分析
这次作业是OO翻车的第一次作业。可以说多线程迈出的第一步是非常艰难的。首先由于作业由提前输入改为实时输入，以前作业的算数式运行方法可以说完全废弃了。因此这次作业中我尝试了模拟楼层和电梯按钮的方法。这次作业当中我认为最大的问题就是调度器和电梯关于捎带的逻辑过于混乱。调度器和电梯中都有关于捎带的判断部分，并且整个电梯的多线程同步比较混乱，因此最后运行起来就会“缺斤短两”，经常漏掉一部分可以捎带的请求。
这次作业拿到的他人代码是一个大佬的代码，仔细学习了其代码后发现我自己的代码果然耦合程度过高，一个方法一二百行。这一点在下次作业当中得到了改善
IFTTT
度量
类图
时序图
分析
这次作业是OO翻车的第二次作业。多线程电梯后痛定思痛的我早早开始了IFTTT作业的研究，但却在设计上花费了过长的时间，导致最后写代码的时间压缩太多，并且当中很多奇奇怪怪的小问题没有妥善解决。实际上后来在看过互测同学的代码后我发现我很大程度上误解了这次的作业......
这次作业当中我设计了一个全局HashMap用于存储和跟踪文件的信息。HashMap当中，作为Key的是一个由我自己设计的可以唯一表示某个文件的字符串，Value则是封装好的SafeFile对象。这个思路的初衷是为了保证全局的修改只针对一个SafeFile对象（因为线程安全是放在一个对象上的），乍一想非常美好，因为Key可以忽略SafeFile内部文件的变更而实时跟踪。但这个思路存在着非常大的漏洞（而我发现的太晚了），即对于用户的测试来说，用户每监控一个文件都需要调用测试的方法，而测试中的方法和HashMap中的SafeFile建立一一对应非常困难，因为某个文件改名后，其Key并没有改变，但接口并不能生成一个“之前的Key"。
实际上在看了互测的代码后我发现，根本没有必要保证这种全局的修改，因为可以使用Snapshot的方式不断扫描来解决。因此自创思路的风险还是很大的，并且实现过程中会有各种各样的小问题。除此之外这次由于debug时间过短，乱加synchronized导致最后写入detail出现了阻塞，也因此跪了很多个公测点（他们产生的原因都是一样的...）
出租车
度量
类图
时序图
分析
这次作业终于站稳了没有翻车。在IFTTT后我进一步对多线程进行了思考，发现分清楚什么时候要加synchronized很重要，以及很多情况下根本不需要使用wait和notify，乱用反倒会导致阻塞的出现。这次出租车作业的需求也比较明确，为了将来作业的可扩展性，我将地图上的点和边均进行了对象化，并且用边来构成路径让出租车运动。这次作业中实际上线程安全的部分并不是很多，而且主要的处理办法就是给方法加synchronized，也没有出现什么大问题。这次的唯一BUG居然是没有注意到忽略同地点请求的要求，比较可惜。设计方面没有被报缺陷。
这次拿到的代码没有以前两次那么好了（说明掉段了），艰难的阅读代码后（代码风格实在是emmm），发现了一些代码逻辑方面的bug，以及报了一些设计方面的缺陷（主要是代码风格比较差）。
心得体会
相比于前三次作业来说，这三次作业（尤其前两次）着实给自己浇了一盆冷水。最大的收获我认为就是，少空想，多写代码。码代码的过程中伴随思考才是最好的方法，为了完美而通过空想的方式提前计划好是很难的，因为总会在代码过程中发现自己漏掉了很多细节。出租车作业中我想一点写一点的方式效果就比前两次拖到最后写好很多。希望下一阶段可以继续提升自己（找回段位）