OO第二次單元總結

OO第二次單元總結

前言

第二單元的三次做業：系列電梯與多線程。

第五次做業

(1)設計策略

電梯的第一次做業是單部傻瓜電梯，採用FAFS調度策略，電梯按隊列順序依次處理請求，單次只處理一個請求。本次做業採用了簡單的生產者-消費者模式，而調度器則採用了單例模式。

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

類圖：

複雜度分析：

依賴度分析：

本次做業很簡單，共設計了四個類，除主線程外包含一個請求輸入線程和一個電梯線程。Scheduler類爲單例模式調度器，內部有一個請求隊列。Input類負責請求的獲取和存入，每當獲取到一個有效請求時，調用調度器中add方法存入隊列。Elevator類爲電梯類，調用調度器中getArray方法獲取請求並執行。類各有分工，便於拓展下一次做業。

(3)分析本身程序的bug

因爲本次做業調度方法很簡單，線程交互也不復雜，因此在公測和互測中並無發現bug。但在寫的過程當中遇到的最大問題是沒法關閉電梯線程，後獲得解決。

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

因爲設計簡單，大部分人代碼量很小，因此主要採用了閱讀代碼的方式尋找別人的bug。

第六次做業

(1)設計策略

電梯的第二次做業爲單部可捎帶電梯，採用ALS調度策略。和上一次做業相比，只是增長了負樓層以及改變了調度策略，所以設計模式徹底繼承於上一次做業，作出了部分改變。

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

類圖：

複雜度分析：

依賴度分析：

本次做業也是四個類，除主線程外兩個線程。Scheduler類調度器負責存儲和分配請求。Input類負責請求的獲取和存入。此次，在Elevator類中增長了一個請求隊列，用於存儲主請求及其可捎帶請求，電梯每到一層與請求隊列進行交互，從而判斷乘客的進出。因爲設計缺陷，Elevator.run方法過長，從由圖中能夠看出，其複雜度很高。

(3)分析本身程序的bug

因爲最後時間緊迫，此次做業在寫完進行很簡單測試後便提交了，經過了中測。但在強測中，發現了致命bug而未進入互測。bug不涉及線程安全，而是調度算法的缺陷，當電梯到達某一樓層時，我採起先下後上，當所有下去後(隊列爲空)，我須要從隊列取出主請求，來判斷是否能夠上，這時便會報錯error。當我改爲先上後下，問題就不存在了。以後應該合理安排時間，多編寫測試樣例，避免低級錯誤。

第七次做業

(1)設計策略

電梯的第三次做業爲多部多線程智能(SS)電梯。單部電梯的調度策略上，我仍採用了上一次做業的可捎帶(ALS)調度。和上一次做業相比，由一部電梯變爲三部電梯，並且這三部電梯的可停靠樓層、運行時間、最大載客量都不相同。最大的限制在於可停靠樓層不一樣，所以乘客可能須要在中間換乘才能到達目的地。最後，我採用了最簡單直接的方法，將請求固定地拆分紅兩個請求，而後存入隊列，等待執行。所以，本次做業設計模式基本繼承於第二次做業，並作出了部分改變。

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

類圖：

複雜度分析：

依賴度分析：

本次做業共五個類，除主線程外一個輸入線程，三個電梯線程。此次新增長了一個Request類，用於將PersonRequest拆分後封裝新的請求，有五個屬性，增長了id和request，分別用於存放執行電梯號和換乘前請求。其它類的功能和上一次做業同樣。Elevator.run方法繼承於上一次的代碼，因爲時間不夠，過長的問題沒有解決。因爲調度器的調度方法採用硬編碼的形式，由一系列if-else組成，所以很明顯，Scheduler.add方法複雜度很高，幾乎沒法拓展。

(3)分析本身程序的bug

性能較差，但在公測和互測中並無發現bug。

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

在互測中仍主要依靠閱讀代碼來發現bug，但效果很很差。

總結

這一單元三次電梯做業讓咱們對多線程有了由淺入深的瞭解。但拋去暴力輪詢的方法，我對wait和notifyall的使用還不夠熟練，總會出現不少問題，在以後的學習中會多加練習，爭取掌握。此外，在代碼設計上仍有很大的不足，缺少明確的設計而致使部分方法過長，先寫後修難度很大，複雜度也很高，以後的做業中，要儘可能在寫以前設計分配好各方法，對代碼風格和debug都有幫助。下一單元，繼續努力！