面向对象第二次课程总结

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

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

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

• 第七次做业：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”中间有个空格，应该要想到路径中可能出现空格，就不该以空格做为各字段的分割符了。