面向对象第二次总结作业

         这三次作业是我第一次接触多线程，这部分的程序有许多过去不曾考虑过的问题：资源互斥，线程同步，线程通信等。到了第七次作业，再从设计规范的角度审视自己的程序，发现自己有不少习惯要改。（这三个星期让我又回想起了计组p5的日子

作业五 多线程电梯

         我本次的设计主要包括电梯类，输入类（请求模拟器类），调度器类。输入通过请求队列将请求传递给调度器，调度器通过信号灯类判断同质，给电梯分配任务从而调度电梯类。

         本次是第一次写多线程，对多线程的各种概念，语法，用法都是第一次学习。这次的共享资源有请求队列（输入，调度器），信号灯（调度器，电梯*3），和电梯（调度器，电梯*1）本身三个。写这次作业的过程中为了边界情况做了不少努力，所以通知板上说重点不在边界情况时有些心情复杂。鉴于花费了我大量时间，我还是把整个历程写出来。

         首先是同质。上次作业的主要难点在这次变成了一个与之前完全不同的小问题。因为一般思路是输入立刻看当前那些请求已存在，然而判断和输入有个小时间差，而且判断只要毫秒数相同就算同质。所以我干脆让信号灯记住上一个请求结束的毫秒数，与该请求记录的输入时间对比，这样就不出错了。

         然后是累积误差的问题。sleep与sleep中间的计算时间会累积从而体现为结果的错误，即作业要求上没有允许计算有可见的时间。所以就用假时间，理解成电梯跑的同时程序运行，每次sleep到理论应该sleep到的时间就可以了。

         最后是重点，为电梯分配任务时需要扫描请求队列，然而电梯状态可能中途改变。只把电梯的方法锁住是不够的，需要在扫描时将三个电梯对象都锁住。然后，依然无法避免的是，理论上同时开始的线程，理论上应同时结束，但总有误差。若在只有部分电梯结束的时候被锁住，应按运动量分配的任务会随机分配。实在没想到什么办法，只好让每次分配中间sleep的时间长一点，降低这种情况发生的概率（这可以说是解决冲突的万能方式，可惜只能降低概率）。

         大概是花费的时间太多，没有被挑出bug。对面公测错了几个，但自己只找出一个小bug。对面为了消除误差，把时间都约成秒，导致同质判错。

 

 

 

 

类图有些乱，线多的Request类里面几乎没有逻辑，作为请求元素在所有类间传递，空间够其实可以摆得清晰些。这次的ReqQue类并没有真正起到作用，不如和调度器的wait数组合并。

作业六 IFTTT

         作为一个确实在应用的东西，我是头次听说IFTTT（孤陋寡闻的我）。由于上一次在“边界情况”浪费了大量时间，我周一看了下，周二才写（电梯是周日开始写的）。然后时间明显紧张了许多，我提交的时候还出了点问题，差点无效，在这里感谢一下助教和课程组。

         这次我主要的类包括安全文件类，检测器类，输入类。检测器不断搜索文件树，与之间的文件对比。

         由于对文件操作不是很熟悉，所以在写的时候有过一些错误的观念，比如以为renameTo之后file对象的路径会相应改变，实际上并没有。

         由于可以规定两次操作间的时间，所以并没有让扫描的同时禁止修改。在同步上的努力就只有锁上文件的方法然后文件使用单例模式（不知道一个文件只有一个对象叫不叫单例，先这么叫着）。

         这次由于指导书看的没有很仔细（作死晚开始），被找了6分，基本都是没看到或知道是理解有差异。有一个是第一条指令之前必须sleep的问题。（真是很普遍，有人因为这个被挂满还要慢慢申诉）。

         除公测（输入判断）没有找出对方bug。

 

 

结果我最后还是没太注意每个方法的复杂度。判断是否改变的方法其实可以变成4种判断改变。

 

 

作业七 出租车系统

         我这次的类主要有调度器（请求队列类），出租车类，请求类，输入类。出租车100个线程，调度一个线程，输入一个线程。问题与解决方式基本类似于电梯。

         与以往不同的是这次的需求分析文档和编程规范的要求。写需求分析文档是我对开发有了更多了解（不懂开发）。然后是我被挑了一堆编程规范的问题，命名时使用缩写（这真的是问题么），出租车类过大等。

         我找了对方输出的细节问题，没找到合适的叶子挂了个新的，后来才知道助教会去掉他觉得不合理的新叶子，说不定对方还没看到求被删了导致没申诉（然而就一个incomplete也没什么好申诉的）。

 

 

这次最复杂的方法是gui的draw。