OO第二次阶段性总结

终于，终于又到了写博客的一周。能够说这三周的做业相比前三周来讲的确是翻车了，不过翻车当中也有进步，从多线程电梯的不知所措到最后出租车可以有条理的写程序，感受本身在这三周做业当中学到的知识比前三次要多得多。

做业分析

多线程电梯

度量

类图

时序图

分析

此次做业是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，以及报了一些设计方面的缺陷（主要是代码风格比较差）。

心得体会

相比于前三次做业来讲，这三次做业（尤为前两次）着实给本身浇了一盆冷水。最大的收获我认为就是，少空想，多写代码。码代码的过程当中伴随思考才是最好的方法，为了完美而经过空想的方式提早计划好是很难的，由于总会在代码过程当中发现本身漏掉了不少细节。出租车做业中我想一点写一点的方式效果就比前两次拖到最后写好不少。但愿下一阶段能够继续提高本身（找回段位）