OO第二階段總結

（1）設計思想簡介

OO第五次做業

　　三電梯調度做業中，第一次嘗試了java多線程編程，對多線程控制的理解及其淺顯，僅僅採用了synchronized和sleep的方法來避免多線程的衝突。即電梯每100ms掃描一次狀態，調度器每100ms分一次任務，而且用sleep把二者錯開來防止衝突產生。可是因爲運算自己消耗時間，在超大數據的測試下，二者會漸漸交合，仍是會出現問題。

OO第六次做業

　　IFTTT文件監視做業中，對多線程的認知有所加深，使用了鎖代碼塊的方法來防止進程不安全的問題產生。同時也重寫了file類，來確保進一步的線程安全。

OO第七次做業

　　第一次打車做業中，進程不安全的狀況較少，處理起來較爲容易，經過整合調度器，即每一個週期掃描一次調度隊列，而非每一個請求單獨一個線程，有效地避免了衝突。

（2）基於度量分析代碼

OO第五次做業

類設計以下：

事實上電梯邏輯原本很簡單，即每個請求進入隊列後，由分配器分配給電梯，若是是電梯內請求，就直接點亮電梯內的按鈕。若是是樓層請求，就按優先級將按鈕點亮並記錄由哪臺電梯來相應，即FloorButton類中elvId這一屬性。這也變相地爲每臺電梯就構造了一個請求隊列。而電梯本身運轉的方法和以往的做業同樣。可是考慮到輸出的問題，每一個電梯還須要記錄本身請求的詳細信息，爲了知足要求，這裏直接將request的序號記錄在了button類中，實屬不智。

可是，在度量層次上卻出現了極大的問題。

能夠看到，在圈複雜度和嵌套塊深度上電梯類均出現了過於複雜的狀況。沒錯，在以前的做業中，調度器負責告訴電梯幹什麼，電梯只須要向哪走就行。而本次做業，調度器負責的是把任務分給電梯，但電梯本身還須要判斷先執行哪一個後執行哪一個，至關於集成了以前做業的Scheduler，在實現上，因爲scheduler的任務和電梯是徹底同時的，因此設計成了一個類，一個線程，卻在度量上出現了大問題。

 

OO第六次做業

類圖設計

本次做業採用了每一個觸發器一個線程的思路，可是在實現上爲了統一出現了一些不明智。

因爲path-changed的存在，當其檢視對象爲文件時，須要檢視文件的父目錄，當我在線程中掃描本文件消失時，便會掃描文件父目錄下的全部目錄以檢查文件移到的位置，可是我將renamed也設計成了同樣的邏輯，只不過一個是限定，必定不在父目錄下，且名字同樣。一個限定必定在父目錄下且名字不同。可是掃描時使用了相同的遍歷方法。這致使了一些bug的出現。

圈複雜度始終是沒法逾越的難關，因爲輸入的不肯定性，對輸入的判斷每每伴隨着不少ifelse，本次做業光合法就有10種狀況。。。這便致使了main中對輸入的處理的複雜度太高。。。

 

OO第七次做業

 

圈複雜度幾乎是沒有問題，可是嵌套塊深度過大，通過一番查詢，發如今調度過程當中首先掃描了隊列中的請求，每一個請求又掃描了全部的出租車是否符合條件，當搶單窗口關閉時，又要掃描全部的符合條件的出租車來肯定派單給誰，三層大循環加上無數的邏輯判斷致使代碼塊過深。

（3）bug分析

OO第五次做業

第五次做業出現了一個bug，出現了在某些及其稀少的狀態下請求丟失的現象。

但調試信息卻顯示請求被正確地分配給了電梯，且電梯正確地接收到了指令，但卻沒有執行。

測試他人bug的時候發現了對方在實現中出現了當電梯都被佔用時，新進入的指令不會被分配給符合條件的電梯的狀況，大概是判斷邏輯中對比部分出現了失誤。

OO第六次做業

第六次做業出現了當父目錄過深，掃描所需時間過長致使測試線程的下一步操做已經進行，致使recover失敗的狀況。應該使用更安全的線程控制，而非單純地sleep，掃描結束以後才交鎖可能比較好。

測試他人bug時發現了一些sizechanged時不觸發modified的狀況。

OO第七次做業

第七次做業並無被測試出bug

第七次做業並無測試出對方的bug

（4）總結

總的來講，對多線程的認知是愈來愈深，又學了os，對同步控制也不只僅是synchronized這麼簡單，在寫代碼時也思考了不少關於面向對象思想和多線程控制方面的方法，確實是收益頗多。基於度量來看，總有一些代碼的狀況分類過多，致使邏輯複雜度較高。可是在當前情景下，我已經儘可能地分配了職責，彷佛有些類的職責確實複雜，有的類就是比較簡單。。