面向對象第八次作業

代碼分析

第五次作業 多線程電梯

UML圖和協作圖

代碼複雜度分析

這次作業的主要難點在於對於多線程的理解和實踐，一方面由於老師上課講的著急，內容也更多的偏向JVM的介紹，因此對於多線程編程的一些思路和方法沒有多少瞭解，另一方面由於時間不足也沒有時間去更詳細的自學多線程，因此基本上只能依靠自己在敲代碼的過程中和debug過程中的探索和對於其他人的代碼中的多線程思想的借鑒來實施。

另一方面，由於之前幾次的電梯都是模擬時間，從這次開始突然變成真實時間，因此以前所寫的所有內容幾乎都不可用，只有輸入輸出部分可以稍作修改，其餘的控制等部分完全是依靠模擬時間的方法。如果之前就知道這次作業要用真實時間，之前幾次作業即使可能會因為超時被報incomplete，我也不會使用模擬時間，一方面模擬時間對於同質和捎帶請求無疑更難判斷和處理，另一方面模擬時間對於本次作業基本沒有幫助，同質和捎帶的判斷都要重新設計演算法重新實現。

BUG

本次作業出現了兩個bug

1. 不能複製多行輸入，如果複製多行，只能讀取第一行，但是如果先讓讀取控制台的Scanner sleep一段時間再開始，輸入的多行數據都能被讀入，而且輸入時間相同。原因未知。
2. 理解錯誤，將每行指令數和指令行數的要求弄反

第六次作業

UML圖和協作圖

代碼中涉及到的線程及其協作關係：

代碼複雜度分析

在完成多線程電梯的任務後，對於多線程的編程有了進一步的瞭解，本次作業的主要難點在於對文件信息進行讀寫操作時的衝突問題，通過對SafeFile的類鎖加以解決。

另一方面，由於IFTTT本身的難點以及作業指導書的不明確、多次修改，甚至還有多次的反覆變更，很大程度上增加了完成作業的難度以及產生Bug的可能性，尤其是在已經完成編程開始debug時，一般都不會再關註issue的內容，因此不知道與之前的要求相衝突的地方，給別人報了不符合之前要求但是符合後來要求的bug，也給自己帶來了bug。

BUG

1. 我不允許對已設立的文件/目錄的任何子目錄/父目錄再建立任何監控，助教表示這個不行
2. 因為在更新文件快照的過程中，傳參部分存在一些bug，影響了change-path後的recover操作和輸出的文件信息
3. 作業指導書的衝突。最開始的作業指導書要求在文件消失後出發size-changed 到0KB的操作，但是最後的issue內容變成了不觸發任何觸發器。

第七次作業

UML圖和協作圖

涉及到的各線程和操作流程圖：

代碼複雜度分析

本次實現的計程車調度系統需要以下幾個對象之間進行交互：

1. 乘客請求：發出請求，請求將被系統內開發的請求處理RequestHandler所捕獲，然後針對每一個被捕獲的請求，設立其對應的請求線程用於實際執行該指令
2. 請求線程：用於實際執行該指令，被請求處理模塊建立，掃描指令發出地周圍的計程車信息，判斷那些計程車可以接單，那輛計程車最後將被派單；在該線程中，也將建立新的線程BFSThread用於獲得圖中各點到出發點和目的地點之間的距離信息
3. 地圖：用於存儲輸入的地圖信息和獲取距離信息、判斷連通等地圖操作
4. 計程車：在沒有被派單時隨機移動，在被請求線程派單後，每次通過地圖獲得下一步運行的方向，知道到達目的地轉入隨機運動為止

因此，系統中主要包括以下四個主要的類：

1. RequestHandler：處理輸入請求，判斷請求合法性，開始請求的執行
2. RequestThread：每個請求的實際執行者
3. Map：管理地圖信息，進行地圖操作
4. Taxi：計程車

BUG

還在申訴中的bug：

時間增量：我是計算的系統時間而不是額外使用一個計數器存儲時間，因此一定會有誤差。有些人使用的是一個基礎數值不斷+200，我認為這個是假時間，而對面的測試者認為我輸出的真實時間反而有問題

派單時刻：readme中有寫，如果派單時計程車正處在兩個位置點之間，即sleep 200ms時，將在醒來後開始處理派單。測試者認為需要立即處理派單。

尋找bug的策略

在尋找自己的bug的時候更多的靠的是編碼前的設計和編碼時的思考，還有在結束編碼後的自行構造有針對性的測試。

在尋找別人的bug時，先大致的找到對方一些可能出現的bug，包括基礎的功能、一些複雜情況下的測試、邊緣測試還有作業指導書不斷修改過程中前後並不完全一致的以及不明確的要求，然後利用自己構造程式、debug的過程中發現的一些易錯點和較為複雜的測試點進行測試。

在發現一些問題後，大致閱讀代碼找出錯誤位置，思考是否存在其它有關聯性的bug。

心得體會

1. 在正式開始編碼之前充分設計、驗證演算法
2. 編碼的過程中測試
3. 修改代碼時考慮修改的影響
4. 構造前參考issue裡面其他人的疑問
5. 不要糾結於邊緣點。邊緣點的情況畢竟是少數而且發生概率極低極低，另外由於多線程的執行情況不可預料，發現到可能的邊緣點後稍微註意一些，不要過多關註即可。
6. 設立DEFINE類或者interface。java中沒有C語言的#define，可以單獨設立一個interface，其中定義一些常亮，在需要使用的類中將其實現即可。
7. 合理設計數據結構，適當利用LinkedList，LinkedBlockingQueue，HashMap等
8. 關註README修改，以防出現readme前後衝突的情況被測試者挖坑。