面向對象第二次課程總結

從多線程的協同和同步控制方面，分析和總結本身三次做業來的設計策略及其變化

• 第五次做業：三個電梯三個線程，對輸入的處理有一個線程，電梯的調度一個線程。

• 第六次做業：每一個監控對象爲一個線程，對輸入的處理一個線程，輸出到文件中各一個線程。

• 第七次做業：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」中間有個空格，應該要想到路徑中可能出現空格，就不該以空格做爲各字段的分割符了。