第五次作業：多線程電梯

多線程的同步和控制

在本次作業里，請求發生器不斷往請求隊列里加入電梯請求，主調度器不停將電梯請求分發給從調度器，從調度器不斷讀取請求來操控電梯運行，因而這三者之間存在同步關系。

請求發生器和主調度器之間共享了主請求隊列，因而需要對主請求隊列的加入、刪除和讀取方法均作同步，對此我采取的方法是在調用者的調用代碼里加入synchronized代碼塊。

主調度器和從調度器之間共享了電梯和從請求隊列，在獲取電梯的方法里我采用的對方法作synchronized同步，對請求隊列的同步采用的與2相同的方法。

OO度量

類圖

類圖展示出了各個類之間的引用，共享關系。缺點是類圖太過繁雜，引用關系較為混亂。

sequence diagram

設計角度

這次作業感覺嚴重違反了顯示表達原則。 體現在各個常量都直接用的數字表示，沒有用類的靜態變量。 如果以后需求發生變化， 比如樓層高度更改， 電梯個數更改， 就需要修改所有的代碼。 對Single Responsibility Principle運用得稍好一些， 主調度器就負責分派請求， 從調度器負責從自己的從隊列里拿出請求操控電梯運行。 主調度器與請求發生器之間就是消費者與生產者的關系， 從調度器與主調度器又形成了消費者與生產者關系。

bug分析

公測有一個測試點掛了，互測有一個測試點掛了。都是同一個原因導致的： 拿到請求之后直接先去除了可捎帶的和同質的再將剩余的請求分發。 這樣做的問題在于， 假如電梯1在前往20樓， 掃描新進來的請求有去19樓的， 則我的程序會先把去19樓的請求分配給電梯1，再去看分配的不可捎帶非同質的請求。 假如之后的一個請求是電梯2去20樓且電梯2的運動量小，則之前去19樓的請求應該分配給電梯2。
互測的時候我找到了很多對方的bug，本著和諧6系的原則沒有報。。對方的問題在于代碼邏輯太過復雜， 層層嵌套很多沒有考慮到的漏洞。 隨便多輸入幾條請求就會產生bug。

第六次作業：IFTTT文件監控器

多線程的同步和控制

本次作業主要的競爭出現在summary和detail文件的寫入上。我采取的對summary和detail的寫入方法都加鎖，這樣就能實現不同線程的互斥訪問了。

OO度量

類圖

我覺得寫這次作業的思路還是很清晰的。通過讀取監控命令來開啟不同的監控線程，各個監控線程不斷掃描文件夾查看是否有文件被修改，若有則通過Summary和Detail類來記錄信息。

sequence diagram

設計角度

這次設計遵循了重用原則，將四種監視器的共性數據比如快照，summary和detail記錄器等寫到了父類Monitor里， 四種監視器繼承了父類Monitor，再通過自己的需求來重寫檢測代碼。但是對Single Responsibility Principle遵循得不好，比如InputHandler本該只產生請求， 卻又產生了監視器線程， 這部分原則應由主線程承擔。

bug分析

本次作業公測互測均未被找出bug。我拿到的測試代碼風格很差， 各個類之間交替引用， 很明顯會造成一邊讀一邊寫的情況。 由于代碼可讀性較差， 我直接根據readme進行黑盒測試。 根據bug樹構造不同的測試樣例， 我覺得最容易出問題的就是將recover任務和renamed, path-changed結合起來監控， 容易出現時序問題。 果然對方在這里掛了兩個點。

第七次作業：出租車系統

多線程的同步和控制

此次作業的競爭出現在

調度器派單<-->請求模擬器要加入請求

調度器訪問出租車狀態<-->出租車改變自身狀態
對于1, 我使用了LinkedBlockedList阻塞隊列來避免競爭問題，對于2，我選擇了將訪問出租車狀態、改出租車狀態的方法都加鎖的方法。

OO度量

類圖

sequence diagram

設計角度

這次作業的課程上講了SOLID設計原則，還講了另外12個工程上要注意的設計原則，在測試過程中也會對設計原則進行考量。因此寫這次作業比前兩次更加注意自己的代碼風格。
Single Resposibility Principle和責任均衡分配原則: 地圖負責提供路線， 出租車負責根據路線前進， 調度器負責讀取出租車信息分配請求， InputHandler負責讀取輸入。
層次化抽象原則： 將整個問題抽象為出租車類， 乘客類， 乘客隊列類， 地圖類， 調度器類。
顯示表達原則： 所有的常量替換成類的靜態變量。盡量少采用數組直接存取信息， 比如出租車的信息，本可以用一個數組來保存其位置、狀態、id、credit， 雖然方便，但數組下標容易混亂。所以用一個CarInfo類來保存信息， 每次訪問出租車的信息時， 出租車都根據自己當前的狀態返回一個CarInfo類。

bug分析

本次作業公測未發現bug， 互測發現一個bug： 出租車搶單時間和前往乘客目的地的時間不對。 導致這個問題的原因是系統時間和出租車系統的假時間總會有一定誤差， 我輸出的搶單時間采用的系統真實時間， 而前往乘客目的地的時間又用的出租車系統的假時間，因此在理論上這兩個時間相差過大。將出租車搶單時間改為請求發出時間+3s即可。
測試對方代碼時，我發現對方的代碼里居然有。。指導書根本沒出現的內容。而且根據其代碼來看應該是本次作業的后續作業。。顯然對方要么是有預見未來的超能力，要么是抄的往屆代碼。。本來遇到這種情況也沒什么可說的了，其代碼風格也極爛， 一個文件里有多個毫無關系的類。。類的命名也毫無邏輯，讀起來實在傷神。我最后構造了大規模的請求進行轟炸，最后發現對方的出租車線程在某些情況下會停止運行。另一個bug是。。沒有提交需求分析文檔。。

心得體會

這三次作業完成起來都不輕松， 尤其是多線程出租車IFTTT。前者是第一次多線程作業，后者的指導書太天馬行空。我覺得開始寫作業之前一定要多分析，模擬各種可能的情況， 確定好框架和要采用的數據結構之后才動手寫代碼。否則很有可能寫到一半發現設計有嚴重缺陷而不得不推倒重來。與同學的討論也是極為重要的， 一方面指導書規定的東西有的繁雜，有的簡略，可以互相檢查是否理解到位；一方面作業本身有難度，多討論會發現不同的設計思路， 有的問題也越辯越明， 對完成作業肯定是有不少幫助的。

轉載于:https://www.cnblogs.com/9998-0804/p/8972216.html

總結

以上是生活随笔為你收集整理的OO学习总结（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。