oo第二單元總結

第五次做業

(1)基於度量來分析本身的程序結構

類圖：

設計了六個類，分別爲Ele類，Line類，Main類，Order類，Scheduler類和TestMain類。其中Ele類，Scheduler類和TestMain類，分別爲電梯線程，調度器線程和輸入指令線程。Line類爲請求隊列類，Order類爲單條指令類。Main類負責實例化一個請求隊列對象，一個電梯線程，一個調度器線程，一個輸入指令線程。請求隊列對象，提取從輸入指令線程獲得的指令的屬性，並經過調用Order類，實例化一個新的指令對象並存儲。電梯線程，調度器線程和輸入線程，經過共享請求隊列對象，來實現程序的協同和控制。輸入指令線程，當輸入指令爲NULL時，會將輸入結束的標誌傳入請求隊列對象，併線程結束。調度器線程，則會在請求隊列對象的請求隊列爲空，而且輸入結束時，線程結束，不然會在電梯指令爲空時，將指令隊列的一個指令傳入電梯線程。電梯線程，則在識別調度線程結束，而且自身沒有指令時，結束線程。
本次做業的設計的優勢是，三個線程利於後續程序的擴展。但同時這也是個缺點，由於本次做業並不須要這麼多線程。

度量分析：

Metrics圖中顯示Ele類和Scheduler類的run的代碼塊的嵌套過深，由於對線程是否結束，是否修改請求隊列對象等的判斷嵌套過多。

(2)分析本身程序的bug

第五次做業互測出現了一個bug。bug爲，當前線程知足結束條件時，線程在wait()，沒有notifyAll()，使得線程一直未結束，CPUtime超時。

(3)分析本身發現別人程序bug所採用的策略

依然是經過觀看別人代碼的方式，但並未發現BUG。

第六次做業

(1)基於度量來分析本身的程序結構

類圖：

設計了七個類，比第五次做業多了一個Eleob類，電梯線程和調度器線程共享Eleob對象，Eleob對象會鎖住電梯將要執行的指令序列，所以調度器線程會經過Eleob對象判斷，是否請求隊列有可捎帶的指令，如有，則傳入電梯線程的指令序列。而電梯線程則經過Eleob對象，判斷主請求和當前樓層是否須要執行指令。調度器線程比第六次做業多了判斷捎帶的方法。剩下的基本與第五次做業類似。
本次做業的設計的優勢依然是，三個線程利於後續程序的擴展。但同時這個缺點在本次做業獲得了巨大的體現，由於線程過多，出現了線程不安全問題，所以須要仔細謹慎處理衝突，結束等問題。

度量分析：

Metrics圖中顯示，Ele類和Scheduler類的run的代碼塊依然嵌套過深，並且Ele類和Scheduler類的圈複雜度過大，由於對wait()和notifyAll()的判斷和使用。Scheduler類的addone方法，即判斷捎帶的方法，的參數數量過多，由於判斷是否要捎帶的條件過多。

(2)分析本身程序的bug

第六次做業有一個巨大的bug。Bug爲，設計上的BUG，對共享對象請求隊列對象的wait()和notifyAll()出現了問題，以及對電梯線程的指令序列的保護出現了問題，總結來講，線程出現了不安全問題。

(3)分析本身發現別人程序bug所採用的策略

依然是經過觀看別人代碼的方式，但並未發現BUG。

第七次做業

(1)基於度量來分析本身的程序結構

類圖：

設計了八個類，比第六次做業多了一個Outcon類，三個電梯線程共享Outcon對象，Outcon對象會鎖住輸出，所以電梯線程會經過Outcon對象避免輸出的衝突。同時調度器線程再也不負責捎帶，只負責將請求隊列的指令按照其不一樣的屬性傳入不一樣的電梯線程。指令的捎帶判斷放在了請求隊列類裏，由於一個指令最多須要兩個電梯就能執行完，所以在請求隊列裏判斷獲得，一個指令由一個仍是兩個電梯執行，以及怎麼執行。剩下的基本與第六次做業類似。
本次做業的設計的優勢是，指令由哪一個電梯執行的判斷簡單直接。缺點是，指令的調度策略會不好。

度量分析：

Metrics圖中顯示，Ele類和Scheduler類的run的代碼塊依然嵌套過深。Ele類，則由於每一個電梯線程的電梯編號，上升或降低的時間，最大載客量等屬性須要傳入，使得其參數數量過多。Line類的addline方法，由於須要對9種電梯指令分配狀況進行判斷，不斷地使用if-else語句，使得其圈複雜度太高。ELe類的getin方法，判斷是否在當前樓層開門並捎帶，由於限制了最大載客量，須要對當前的電梯人數，主請求，當前樓層的請求等綜合判斷後，才能決定是否在當前樓層開門捎帶，所以圈複雜度太高。Scheduler類的comput方法，則由於其須要判斷當前指令隊列是否有能夠調度的指令，以及將該指令給哪一個電梯，所以圈複雜度太高。

(2)分析本身程序的bug

由於第六次做業的不斷地解決BUG，所以本次做業在其基礎上擴展，並未被發現BUG。

(3)分析本身發現別人程序bug所採用的策略

依然是經過觀看別人代碼的方式，但並未發現BUG。

SOLID原則分析：

單一職責原則(SRP)：每一個類專一於單一明確的功能。
開放封閉原則(OCP)：基本知足。
里氏替換原則(LSP)：沒有子類設計。
接口分離原則(ISP)：沒有接口設計。
依賴倒置原則(DIP)：沒有抽象類設計。

心得體會

(1)在考慮和設計線程之間的交互時，須要明確當前線程的職責，而後明確交互線程之間在哪些數據之間造成了交互，這些數據是否可能會發生衝突，是否須要加鎖。 (2)訪問控制都是在線程類代碼中實現的，下一步將學習如何在共享對象中實現。 (3)加鎖的時候，依然是鎖住整個對象，如何只鎖住關鍵部分就能達到效果，是下一步須要不斷探索解決的問題。