面向对象第二次课程总结

从多线程的协同和同步控制方面，分析和总结自己三次作业来的设计策略及其变化

• 第五次作业：三个电梯三个线程，对输入的处理有一个线程，电梯的调度一个线程。

• 第六次作业：每个监控对象为一个线程，对输入的处理一个线程，输出到文件中各一个线程。

• 第七次作业：100辆出租车各一个线程，对输入的处理一个线程，调度器分成两个线程。

基于度量来分析自己的程序结构

第五次作业

截图

BUG分析

　　公测被发现了一个BUG，先输入(ER,#1,10)之后暂停3-9秒再输入(ER,#2,10);(FR,4,UP)。但这个我在本地测了好几次结果都是对的，同学和助教测试就出了问题，很迷。

第六次作业

截图

BUG分析

　　在第六次作业中，由于未考虑输入的文件路径中可能含有空格，而使用了空格作为各个输入字段的分隔符，导致了互测时被报了一个BUG。

　　由于这次指导书很多地方都没有明确的规定，只对对方做了一些功能性测试，未发现BUG。

第七次作业

截图及分析

在这次作业里，调度器的两个类中都有run方法过于臃肿的缺点，由于设计时没有仔细的思考调度器的实现，还是在写的时候，想到哪里写到哪，导致一个方法的功能太多。程序设计时，注意到给出的广度优先算法有些问题，求一次最短路径长度需要100+ms，而且保存的二维数组在计算下一次最短路径时又被全部清零了，导致可能需要计算一个值很多次，故将其修改为对每个目标点只计算一次，考虑在3s中的抢单窗口关闭前，就能将之后需要的值计算完，就没有再做进一步的优化了。

BUG分析

未对gui.java中的求最短路径的方法进行优化，同时输入请求数量较多时，运行时间较长，无法控制在抢单窗口关闭后较短时间内完成对所有请求的分配……

对于求最短路径的方法，我只是考虑了算过同一目标地点的不需要重复计算一次，而没有去对gui.java中提供的方法进行优化。同时，为了缩短测试者测试程序需要的时间，未在地图读入时将所有节点的最短路径长度都计算完成后才允许读入请求，这也导致了同时输入请求数量较多时，无法在3s内完成所有所需节点最短路径的计算。测了下，用给出的方法一个点得跑个100+ms，6400个点起码得跑个十分钟的。看来下次得先初始化完成后再让测试者输入.

╭(╯^╰)╮好吧，其实还是需要去优化一下算法吧。emmm，发现了的确是自己的问题，还是得感谢一下测试我程序的同学。

心得体会

　　这几次的作业，感觉比之前的难了很多，写程序之前一定要先仔细阅读指导书，将需求弄清楚，先设计好程序的各个类和方法，而不要在写的过程中想到一部分功能就在run里写一部分代码，这样很容易导致BUG，还不易调试。思考问题也应更全面一些，比如鬼畜的“C:\Program Files”中间有个空格，应该要想到路径中可能出现空格，就不应以空格作为各字段的分割符了。