OO第二次博客做業

第五次做業：三部電梯的多線程調度

度量分析：

類圖：

 

度量分析中: scheduling方法是電梯調度的主要函數，因爲須要依靠指令和電梯狀態來判斷同質與捎帶等等，嵌套得比較深，另外函數體也過大，複雜度有點大

從類圖中能夠看出各個類之間還算均衡，電梯類比較大，主要是它要記錄的一些狀態及相關標記比較多，便於調度時候進行判斷。本次做業我是推翻重寫，雖然第二次ALS電梯的2個bug我已經改正了，不過自我感受第二次電梯的代碼十分冗餘，有不少能夠優化的地方，再加上這是第一次寫多線程程序，不但願之前不成熟的代碼對本次形成影響。寫這三次電梯代碼，發現每次增長一點難度，代碼卻並無增長不少，甚至第三次的代碼明顯少於第二次電梯的代碼，主要緣由應該是對之前的功能更加熟悉，在代碼實現的時候作了很多優化，重構了實現方法。本次做業的難點仍然是捎帶和同質，因爲是三部電梯，另外還有均衡原則，捎帶和同質的判斷以及任務分配有點複雜，最主要的是多線程的玄學問題。說實話完成此次做業的時候我對多線程的理解和運用能力仍是十分不足，萬幸，此次做業沒有bug.

第六次做業：文件監測

度量分析：

類圖：

 

 先從度量分析看起：run方法過於複雜，嵌套深；

從類圖中感受各個類還算均衡；

此次做業從個人構思開始就已經有點錯誤了，按照個人設計思路，每一條監測請求都開一個線程，是以那四個觸發器爲中心，這樣的設計存在漏洞，好比同一個監測對象，若是擁有四個監測行爲觸發器，若是有recover行爲，那其餘的觸發器是否觸發就不可預測；另外，我沒有考慮能夠複製粘貼一個文件，這樣的文件除了文件名，其餘屬性都相同，並且我觸發器判斷條件有漏洞，好比對於重命名文件判斷，沒有考慮是新添加的文件，也就是之前不存在的文件，這兩個錯誤加起來就產生了bug.  此外，個人設計思路沒有按照提示的去作，構造snapshot去掃描文件，而是每一個觸發器單獨掃描，這樣明顯存在線程安全和效率問題。事實再一次證實了前期設計思路的正確與嚴謹的重要性；這一次做業的bug有點多，也出現了玄學問題，就不一 一 列出來了。另外這部份內容涉及到文件操做，對我來講又是一個新的知識點，文件操做的安全性考慮也蠻重要。我在百度上看到說多線程寫文件要用文件鎖, 本次做業的SafeFile中使用了方法鎖，另外每一個方法中也使用了文件鎖，不過文件鎖顯然是多餘的。

第七次做業：模擬出租車

度量分析：

類圖：

本次做業的構思：每一輛出租車開一個線程，每個有效請求開一個線程，請求線程的生命週期爲3s，因此一次性輸入的請求數目不能太大。另外schedule類是用來幫全部的出租車進行搶單的，搶單成功便記錄下來，由請求線程進行派單。提供的GUI代碼中已經提供了求最短路徑的代碼，不過我不喜歡用別人寫的代碼（讀懂別人的代碼要花時間，另外本身寫的代碼用起來更舒服，雖然效率可能不高，但本身理解），度量分析裏的紅色部分就是我將輸入文件轉換爲地圖，以及求兩點間最短路徑的代碼。此次做業學到了：對象做爲參數傳遞，以及方法中return一個對象，是比較危險的，由於傳遞的是對象的地址，而不是像基本類型同樣複製一份，這樣的話在其它地方也能夠對對象進行更改。這部份內容老師早就講過，不過我仍是在實踐中操做才深有體會。此次做業沒有bug.