OO第五、六、七次作业总结
一、第五次作业
（一）多线程的协同和同步控制
-
在第五次作业中首次采用了多线程的设计模式。多线程的设计使得对象的设计更具有独立的特性，但是在不同对象之间的交互也需要格外的注意。在此次作业中，经过分析，笔者共有三类线程对象，分别是电梯线程、调度器线程和请求模拟线程（主线程）。再据指导书要求，此次作业需对三个电梯进行调度设计。因此，线程的交互关系如下：
-
请求模拟器线程负责控制台请求的输入，获得请求后将请求送至主请求队列，调度器定时从port获得电梯状态snapshot，然后扫描主请求队列，进行同质请求的判定和请求的分配；各电梯线程进行状态机式运动，并在合适时机扫描各自请求队列执行请求，在每次状态运行结束时更新port中状态。
（二）度量分析
- 在此次作业中，存在问题主要为三个方面：圈复杂度过高，程序参数过多以及嵌套层过深。经过分析，电梯类中主要由于采用switch语句导致圈复杂度和嵌套层过深，但是又因为switch语句用起来结构清晰简单，目前没有较好的解决办法。调度器中主要原因为checkby（检验是否捎带）方法的逻辑较为复杂，同样应该也有采用switch语句的原因。如有同学有更好的代码书写模式欢迎在评论中指出。
（三）作业类图与时序图
（四）自己程序bug分析
- 【Thread-scheduler类，checkby方法，优先级设计失误】
在此次作业中，自己的程序在临交之前由于错误修改了FR请求的分配优先级，导致有三个公测点未通过。因此接下来将对程序中该bug进行分析。在进行checkby中FR请求分配时，采用权值设计法，如果符合捎带请求，权值为100000，否则为0，如果电梯处于等待状态，权值为0，否则为-9999，电梯运动量取负值为权值，再将三者之和相加。在三个电梯中取最高值进行分配。错误原因是：最开始将电梯等待状态权值设计相反，导致错误。
（五）别人程序bug分析
- 无
二、第六次作业
（一）多线程的协同和同步控制
- 第六次作业中，此次作业的重点是线程文件操作安全和文件的监控，因此分别采用如下解决办法：将各个线程对于文件的操作都封装到一个类中完成，将该类视作通往文件操作的窗口，在该类的方法上加以锁确保安全；对于文件监控，每个监控任务建立一个监控线程，初始时建立快照，每次从文件操作窗口获得新快照，对比，若满足触发条件进行触发。线程交互同类图。
（二）度量分析
- 在此次作业中，存在的问题与第五次作业大致相同：圈复杂度过高，程序参数过多以及嵌套层过深。在主函数中，由于同时完成触发任务过滤操作，因而导致圈复杂度较高。在触发器的trigger函数中，因为对于不同的触发任务会触发不同的操作，致使判定较多，嵌套层过深。
（三）作业类图与时序图
（四）自己程序bug分析
- 【Monitor类，trigger方法，参数书写错误】
在进行快照的留存与对比中，采用Hashmap进行储存与对比。其中使用迭代器进行遍历，在新map的遍历中，迭代器变量书写错误导致bug。
（五）别人程序bug分析
- 无
三、第七次作业
（一）多线程的协同和同步控制
- 第七次作业，共有两类线程：出租车线程和系统线程。系统线程进行用户请求的获取与分配，出租车线程进行抢单、接单和服务。线程交互同类图。
（二）度量分析
- 此次作业相较于前两次作业有明显改进，仅圈复杂度较高，GUI圈复杂度我们暂且不管，将重心放在Taxi类上。Taxi类同第五次作业电梯，采用switch语句进行状态机的运动，导致圈复杂度较高。
（三）作业类图与时序图
（四）自己程序bug分析
- 无
（五）别人程序bug分析
- 【Main类，main方法，构思不完整】
如果在程序运行时对应目录下map.txt不存在，程序将直接崩溃。 - 【Main类，main方法，构思不完整】
对于同质乘客请求，未处理。
四、心得体会
- 又经过三次作业的训练，有如下心得体会。
在代码训练上，明显可以感觉到与前三次作业不同，在阅读完指导书后构思、书写行云流水。项目设计与实现的自信心增强了。还记得第一次作业时，进行项目设计时都不是很有自信的。
在知识的学习上，充分了解并训练了线程的使用以及线程安全的使用与设计。真的感觉线程的实现是一件非常有趣的事情。以多线程电梯为例，当使用状态机完成电梯的实现后，真的感觉RUN起来的那一刻有一个真正的电梯运行在我的眼前。这种感觉，真的有点像创造了小生命一样。
接下来的作业我们将对出租车进行进一步的设计，前方仍有未知的危险和难度，仅以下句与诸君共勉：