oo作业总结(二)

概述

和前三次作业相比，这几次作业最大的不同是难度的飞跃。遗憾的是在这难度的变化面前，我自己却没有做好充分的准备，错误的低估了作业难度导致给自己带来了很多不必要麻烦和损失。接下来我将对它们进行说明(度量图工具出了故障一直无法生成请原谅)。

设计简介

第五次作业

这是oo课程第一次多线程作业，我自己也体会到了它的难度。我的设计思路是首先够早一个调度器类(以上类图的scheduler类)，负责管理各种实时输入的指令，然后是有三部电梯在各自独立的运行着，每当有新的指令输入时，首先判断是否是同质指令，然后在三部电梯中按照指导书中的说明来寻找可以处理该指令的电梯，如果没有找到可以处理该指令的电梯则将该指令加入请求队列等待执行；和第二次第三次作业不同之处在于本次作业的输入同质判断可以在输入的时候就可以判断完成；另外难点在于合理处理时间，因为每次处理都是需要消耗时间的，这样就会造成最终的输出可能并不满足相邻楼层时间差为0.5；这是本次作业的难点；

这次作业也使我对多线程有了更清晰的认识；

第六次作业

由于一些特殊原因，本次作业完成了但并没有提交；这次作业一个很大的特点在于思路很清晰，但工作量大，这次作业自己也是煞费苦心（熬了两天夜），无奈最终电脑出了故障导致没有提交（难过）；设计思路是分为两类，对监控对象是目录和文件进行了分类，如果是文件则非常简单，只需要对其进行相应的处理即可；麻烦的是监控对象时目录的情况，这就需要对整个目录进行扫描且处理的细节比较多；处理的大致过程如下：为每个监控对象开一个线程(以上类图中的monitor类，本次作业最傻的设计，没有之一)，时刻扫描有没有发生变化，如果发生变化则报告这条指令的Scheduler线程以此判断是否需要触发操作；

第七次作业

MapInfo类是地图处理和输入类，Main类则是主要线程类。有了前两次多线程作业的预热，本次作业完成的得相对顺利些（其实主要是自己开始写得早）；设计思路是有一个调度器类负责调度指令，一旦有指令输入则对其开一个长度为3s的监控线程(Monitor类)来监控是否有出租车抢单以及在三秒的监控线程结束之后来决定由哪辆出租车来处理该指令；

测试分析

第五次作业

公测:错了三个点，三个段都是因为时间误差

互测:对方没有bug，自己被找了四个点，申述了三个，目前通过两个，还有一个还没结果。错误也主要是各种时间误差。不过就算被找出了bug，自己还是没能解决如果消除时间误差。

第六次作业

 未提交

第七次作业

 公测:格式正确

互测:没被找出bug。对方程序bug蛮多，懒得仔细去查，报了四个incomplete。

总结

 最大的收获是使自己了解了自己的实力。由于前三次作业积攒起来的对oo作业的不重视也一散为空，取而代之的是熬夜熬夜又熬夜。关于测程序是如何测的还是和以前一样，有些东大家都懂，只是说也只有那么少数人才能规范的完成，以及在大量的分数诱惑面前，测程序过程中发生的不愉快也逐渐多了起来，最大的希望是自己在学完oo后不要丧失人与人之间的真诚与信任。