OO第二次博客做业

第七次做业——出租车

本次做业是模拟出租车和乘客交互的系统，对于在地图中的乘客发出合法请求以后，出租车先到乘客地点接单而后再将乘客运送到目标位置。
本次做业中主要须要处理的问题是如何将gui类本身的代码耦合，正常显示出图形界面；如何设计接单窗口时间限制，如何知足多线程安全。
在类的设计上有输入输出处理InputHandler和OutputHandler类，线程有RequestDeal和Taxi，而且由于每一条请求有一个3s的开窗时间，因此对于每条合法请求设计了一个Window窗口线程，处理的结果做为命令传入给选中的出租车。
本次做业中进步之处能够从度量分析中看出来，对于类的抽象更加明确，同时方法的功能相对前几回更加单一，没有出现God类和Idiot类。

（1）类图

类图

（2）度量分析

从度量图能够看出大部分抽象作的不错，方法的功能比较单一。
另外Window类的SendTaxi（）方法仍是抽象程度不够，在写的时候也没有注意将其拆分出独立的单元，这种写法应该在后续做业中避免；另外就是Taxi的计算路径类，每次都会计算一遍最短路径，增长了计算开销，应该能够将第一遍计算的结果保存下来，节省时间开销。
（3）时序图

UML图

（4）Bug分析：
本次做业中不足之处是没有对输入进行严格处理，因此在写判断条件的时候随手写成了下面这种：

if (srcx < 0 || src > 80)

致使挂掉了两个对于80边界条件判断的公测点。
还有一个问题是多线程不安全的设计，对于抢单的隐藏问题没有考虑到，因此同一地点的不一样乘客连续抢单以后，若是抢到同一辆出租车则这两出租车只会相应一个请求，挂点了一个公测点。改进就是在对抢单出租车进行筛选的时候剔除已经被其余乘客选中的便可。

（5）对面Bug：
此次对面做业没有Readme，最开始测试的时候没有导入地图文件，因此程序一直Crash，这是一个没有对文件输入处理try-catch的bug。还有两个没有对合法输入断定的bug。

第六次做业——IFTTT

此次做业是实现一个监控程序，若是监控范围内的对象属性发生变化，就会触发触发器产生对应的措施。监控内容可使文件夹也能够是文件，做业的目标是针对线程安全进行设计，若是平衡共享对象的问题。
此次做业的设计上出现了问题：在和同窗交流的时候发现他们都是将监控文件和监控文件夹做为一个总体编码，也就是说文件是文件夹中只有一个文件的状况，而我则是将监控文件和监控文件夹做为两种状况处理，这种处理方式虽然可以实现功能，可是无疑提升了核心算法的代码量，若是有什么修改则要同时修改两个部分的代码。

（1）类图

类图

从类图能够看出Trigger类的方法比较冗余，其中断定文件和文件夹的方法原本是能够合并在一块儿的。
（2）度量分析

从度量分析可知，对于InputHandler类的work方法处理过于笼统，其实能够拆分为检查格式和提取参数的

（3）时序图

UML图

（4）Bug分析：
在公测中遇到了恶意扣分的状况，对面抓住issue44助教的一句话认为我四个公测点都有bug：没有改变的属性要所有输出，固然这种状况申述就处理了...
考虑不周全的是在文件夹下添加文件夹或者文件不能实现监控，是由于最开始只使用了一次快照，另外就是当文件被删除的时候size被认定为改变为0，程序中没有对删除后的文件进行监控对比。

（5）对面Bug：
策略是首先使用单个数据单线程进行测试，若是没有问题再测试多线程，而后测试文件读写冲突状况。
抽到的做业出现了不少问题，在阅读他的源码后发现没有写path-changed断定，对于触发器的recover也不能实现。

第五次做业——多线程电梯

第五次做业因为最开始接触多线程，同时程序抽象作的很很差，最终捎带都没能实现，具体分析Bug就没有必要了，从类图中能够看出对于类的设计也很是有问题，好比在Main中添加了不少对于输入的判断方法，main主体也包含了不少应该抽象成方法的代码，多线程电梯抽空再重构吧。

类图

总结

1. 第一次多线程电梯写的很糟糕，花了大量时间最后基本功能都没有实现，其中类的规模和不少方法的规模都太大致使维护成本高，修改的过程当中越改越乱...
   作后面的IFTTT和出租车做业时认识到从一开始就设计好是多么重要，从出租车做业开始听从了必定的设计原则（SOLID），减轻了不少编码的负担。
2. 虽然通过了三次多线程做业，可是目前仍是只使用过synchronized和sleep关键词，对于线程安全理解还不够，并发编程还要多加练习。