OO第二次总结性作业
多线程电梯
设计要求
本次作业是设计一套由3部电梯组成的多电梯调度系统，通过采用线程机制，在第三次作业所实现程序的基础上完成新的调度系统程序。
不得不说这次作业相比于前几次作业，难度上有了本质上的提升。第一次接触多线程让我感到十分不适应，无法设置断点进行调试让本来难度就很高的多线程作业显得更加难以琢磨。笔者在开始码代码前，花了大量的时间对课堂上的东西进行回顾，也在网上找了许多java的相关课程，却始终感到难以下手。最终在ddl的逼迫下，才终于迈开了艰难的脚步。不得不说，本次作业虽然和之前有着很大的联系，逻辑上本身也没有太大区别，工作的功能也没有进行很多的改进，但事实上当我写完之后，可以说基本是把之前的所有代码都推倒，重新写了一遍一样。当然这也与我之前总结性博客说的那样，我之前的设计在一定程度上存在缺陷，可扩展性很差，而这一次作业如此大的工作量就是最好的证明。
类图
度量图
分析
由于是第一次接触多线程，且时间紧张，仅仅是能够完成功能以及尽可能地找出bug就已经消耗了大量的时间。虽然初期做了许多准备，但在真正开始写代码时，还是遇到了许多之前没有想到的困难。到处打补丁，拆东墙补西墙，使得类的功能和定位出现了混乱，在一定程度上造就了“上帝类”和“傻瓜类”的诞生。在之后的bug调试以及互测上，在我这个天梯段位，可以看出大家完成基本功能已经是用了九牛二虎之力，对于一些极端情况显然处理得不够仔细。而线程安全性也成为一大扣分点。对于同时访问某一对象，如果不进行恰当的处理，就很容易出现“边读边写”的情况，这就让程序出现了紊乱，甚至是一些难以解释的行为。而多线程又无法进行断点调试，通过输出调试，大大增加了debug的难度。同时，如果不认真思考代码逻辑，只是一昧地全都加上锁，不但会让程序编程名副其实的单线程程序，降低效率，甚至会出现“死锁”的现象，即在一个对象中调用一个锁起来的方法，而这个方法又要调用其他锁起来的方法，这无疑是矛盾的，从而出现了“死锁”的现象。
总结
本次作业对于笔者来说还是算比较大的挑战，再加上每周的os上机以及凉了快半学期的电工实习，笔者是熬了好几天的夜，才在ddl截止前勉强提交上了自己的代码和想到什么就瞎写什么的readme。所幸努力并没有白费，在本次测验中并没有被扣除多少分，自己忽略的问题也同样会被很多同学忽略。通过此次作业，笔者加深了对于多线程的理解（真的是一天速成java，一天速成多线程！！）对于输出调试法也有了很多自己的心得。事实证明，在之后两次作业的编写中，相对于这次作业就要成熟许多，也避免了很多之前没有想到的bug。
IFTTT
设计要求
本次作业的目标是训练同学们针对线程安全问题，如何平衡线程访问控制和共享对象之间的矛盾。 作业内容是实现一个监控程序，针对给定监控范围内的监控对象，以扫描方式探查监控对象相关属性的变化，从而触发规定的处理动作。
不得不说，这次作业真的是被老师和助教给蒙了。在经历了多线程电梯的洗礼后，笔者拖着疲惫的身体，躺在了自己的小床上，安然入睡。课堂上老师，包括课下和助教交流，大家都说多线程电梯是oo的巅峰，过了之后会有一个难度的下降。对嘛，累了这么久，是时候该休息休息了。明白这些的我，心安理得地将oo放在一旁，并勇敢地一直等到周一的晚上才打开它。
信心满满的笔者认为自己只需要一个晚上加一个白天就轻而易举地把这次作业搞定，因为在我心里它大概和智慧电梯的难度差不多。然而，当我真正开始阅读指导书的时候，我才发现事情没有那么简单。首先，本次作业对于多线程的安全性可以说有了更加深入的考察，对于同一个文件进行的操作会触发多个触发器，而在这一过程中无疑会产生很大的安全隐患。除此之外，对于之前从未了解过java的笔者来说，对于java只是一天速成的笔者来说，文件操作到底是个啥？？对于本次程序根本无从下手的我，平复了下自己的心情，开始在网站上搜索java对于文件的操作。如何创建文件，如何移动文件，如何写文件，一切从零开始。在经过了无数次尝试与询问后，终于踉踉跄跄地学会了文件的基本操作，也终于开始打起了代码，看眼时间，嗯，半夜一点
之后的接口也是让我很头疼的地方之一，第一次写这种测试程序，很害怕自己有什么地方没有写好，或者没有考虑到，导致不必要的失分。但自己的程序，还是用自己的测试接口比较保险，如果让测试者自行编写测试接口进行测试，可能会出现更多模棱两可的bug，引起不必要的矛盾。笔者不得不选择放弃本周的电工实习和os，全身心地投入到此次作业的编写中来。
类图
度量
分析
此次作业有了上一次作业的经验，对于类职能的定位都有了更加清楚的认识，就是时间不算很充裕，一些方法可能会写的有些丑，效率上也没有那么高，但本次程序对于线程安全有了更高的重视，防止对于一个文件同时进行读写操作。在调试过程中由于文件移动或重命名使得对象指空从而crash的现象时常发生，在之后的互测中也成为很大的得分与失分点。同时笔者还忽略了一种情况，当两个文件除名字外都相同时，若此时把其中一个文件移走，那么笔者的程序则会把另一个文件认为是当前文件重命名后得到的，而这无疑是错误的，从而导致了失分。笔者对于readme的编写由于时间的限制同样没有很仔细，这就使得与测试者产生了一些不必要的矛盾。
总结
不得不说这次作业真是给我了一次惊喜。其实如果我分配更多时间的话，应该会有更好的发挥，但就是对于自身的过分自信，对于外界言论的过分自信以及多线程电梯后留下的伤疤，让我迟迟没有开始动手。也正是这样，让我在下一次作业的编写中，更加合理地安排时间，从而达到了很好的效果。
滴滴打车
设计要求
本次作业模拟出租车的乘客呼叫与应答系统，开发相应的程序，继续训练线程安全设计方法，同时应用课堂所讲授的面向对象分析方法和设计原则来开展分析和设计
本次作业做好了提前计划，且对于题目有了很深的了解。虽然动手打代码的时间不算早，但可以算是一气呵成，用了一个下午就基本完成了。之后简单进行了调试就可以跑了。不得不说看见一堆红点在地图上跑的时候还是开心地笑了出来。
类图
度量
分析
本次作业整体难度感觉相比于之前有所下降，可能也是自己写了这么几次多线程以后有所提升吧。虽然之后出了一些bug，但基本是自己有些小地方没理清楚导致的，整体上打代码的感觉还是很舒服。基本冲突的地方就是对于一个请求，不捅出租车对它进行的响应。不过本次作业的gui部分以及地图读取部分，都是使用的课程网页提供的代码。如果需要自己读入地图并进行容错处理，以及自己去求最短路径，其实还是很有难度的。
总结
连续三次的oo作业终于结束了，这几周内也一起完成了os的期中考试以及电工实习的期末验收。不得不说这几周以来压力还是挺大的，在最后搞定oo的那一刻，感觉终于可以放松下了哈哈。不过oo的征程还没有结束，下周，让我们重新上路。
