第七次作业——出租车
本次作业是模拟出租车和乘客交互的系统，对于在地图中的乘客发出合法请求之后，出租车先到乘客地点接单然后再将乘客运送到目标位置。
本次作业中主要需要处理的问题是如何将gui类自己的代码耦合，正常显示出图形界面；如何设计接单窗口时间限制，如何满足多线程安全。
在类的设计上有输入输出处理InputHandler和OutputHandler类，线程有RequestDeal和Taxi，并且因为每一条请求有一个3s的开窗时间，所以对于每条合法请求设计了一个Window窗口线程，处理的结果作为命令传入给选中的出租车。
本次作业中进步之处可以从度量分析中看出来，对于类的抽象更加明确，同时方法的功能相对前几次更加单一，没有出现God类和Idiot类。
（1）类图
（2）度量分析
从度量图可以看出大部分抽象做的不错，方法的功能比较单一。
另外Window类的SendTaxi（）方法还是抽象程度不够，在写的时候也没有注意将其拆分出独立的单元，这种写法应该在后续作业中避免；另外就是Taxi的计算路径类，每次都会计算一遍最短路径，增加了计算开销，应该可以将第一遍计算的结果保存下来，节省时间开销。
（3）时序图
（4）Bug分析：
本次作业中不足之处是没有对输入进行严格处理，所以在写判断条件的时候随手写成了下面这种：
if (srcx < 0 || src > 80)
导致挂掉了两个对于80边界条件判断的公测点。
还有一个问题是多线程不安全的设计，对于抢单的隐藏问题没有考虑到，所以同一地点的不同乘客连续抢单之后，如果抢到同一辆出租车则这两出租车只会相应一个请求，挂点了一个公测点。改进就是在对抢单出租车进行筛选的时候剔除已经被其他乘客选中的即可。
（5）对面Bug：
这次对面作业没有Readme，最开始测试的时候没有导入地图文件，所以程序一直Crash，这是一个没有对文件输入处理try-catch的bug。还有两个没有对合法输入判定的bug。
第六次作业——IFTTT
这次作业是实现一个监控程序，如果监控范围内的对象属性发生变化，就会触发触发器产生对应的措施。监控内容可以使文件夹也可以是文件，作业的目标是针对线程安全进行设计，如果平衡共享对象的问题。
这次作业的设计上出现了问题：在和同学交流的时候发现他们都是将监控文件和监控文件夹作为一个整体编码，也就是说文件是文件夹中只有一个文件的情况，而我则是将监控文件和监控文件夹作为两种情况处理，这种处理方式虽然能够实现功能，但是无疑提高了核心算法的代码量，如果有什么修改则要同时修改两个部分的代码。
（1）类图
从类图可以看出Trigger类的方法比较冗余，其中判定文件和文件夹的方法本来是可以合并在一起的。
（2）度量分析
从度量分析可知，对于InputHandler类的work方法处理过于笼统，其实可以拆分为检查格式和提取参数的
（3）时序图
（4）Bug分析：
在公测中遇到了恶意扣分的情况，对面抓住issue44助教的一句话认为我四个公测点都有bug：没有改变的属性要全部输出，当然这种情况申述就处理了...
考虑不周全的是在文件夹下添加文件夹或者文件不能实现监控，是因为最开始只使用了一次快照，另外就是当文件被删除的时候size被认定为改变为0，程序中没有对删除后的文件进行监控对比。
（5）对面Bug：
策略是首先使用单个数据单线程进行测试，如果没有问题再测试多线程，然后测试文件读写冲突情况。
抽到的作业出现了很多问题，在阅读他的源码后发现没有写path-changed判定，对于触发器的recover也不能实现。
第五次作业——多线程电梯
第五次作业由于最开始接触多线程，同时程序抽象做的很不好，最终捎带都没能实现，具体分析Bug就没有必要了，从类图中可以看出对于类的设计也非常有问题，比如在Main中添加了很多对于输入的判断方法，main主体也包含了很多应该抽象成方法的代码，多线程电梯抽空再重构吧。
总结
- 第一次多线程电梯写的很糟糕，花了大量时间最后基本功能都没有实现，其中类的规模和很多方法的规模都太大导致维护成本高，修改的过程中越改越乱...
做后面的IFTTT和出租车作业时认识到从一开始就设计好是多么重要，从出租车作业开始遵从了一定的设计原则（SOLID），减轻了很多编码的负担。 - 虽然经过了三次多线程作业，但是目前还是只使用过synchronized和sleep关键词，对于线程安全理解还不够，并发编程还要多加练习。