面向對象第二單元做業總結

OO第二單元做業總結

第一次做業

做業任務描述

設計一個單部多線程傻瓜調度(FAFS)電梯的模擬， 輸入爲人的ID， 起始樓層和終點樓層， 電梯調度算法要把人送到指定樓層。

問題建模

在此次做業中， 我對問題用一下的方式建模

人在終端中輸入請求， 進入request pool, 而後一個電梯從request pool中拿請求。

請求-》進入請求池-》每當電梯沒有任務時， 嘗試從請求池中拿一個請求

其中， 電梯爲單獨的一個線程， 請求池爲一個單獨的線程， 主線程爲一個線程。

實現與類圖

此次主要功能在三個類中

• RequestPool
  這個類用於獲取請求， 每次獲得一個請求就把這個請求放到ArrayList裏
  
• SingleElevator
  電梯類， 用於管理乘客上下以及得到請求。
  每一個電梯單獨開一個線程， 線程的主要函數以下
  
  一共有如下三種狀況

1. 內部有請求
2. 外部有請求
3. 沒有請求

此次做業基本仍是使用輪訓+sleep的機制， 不斷檢查是否有請求。
每當獲得請求時會先到請求的層

而後接上乘客， 把乘客送到目標樓層

線程分析

此次線程比較簡單， 沒有使用wait和notify的方法， 以後會有用到。

度量分析

第一次做業總體比較簡單， 複雜度控制的還比較好， control flow和design complexity都沒有太複雜的狀況， 類內部的聚合程度， 和類之間的耦合程度作的也還不錯。

第二次做業

做業任務描述

在第一次做業的基礎上， 加入捎帶調度策略。

問題建模

沿用第一次架構， 可是每次電梯在到達一個樓層後會判斷是否有和當前運行方向相同的乘客， 若是有的話， 那麼電梯會捎帶上這個乘客。

實現與類圖

此次和上次做業基本沒有變化， 仍是主要三個類， 其中修改了電梯類。
在每一個樓層檢查有沒有人進入， 有沒有人出去

checkInAndOut()會調用checkIn和checkOut

這兩個方法會檢查有沒有人在當前樓層是目標到達樓層， 以及reqPool裏面是否有請求從這一層上， 而且判斷到達樓層是否在運行的方向上。

線程分析

此次線程用了wait和notify方法， 每次沒有請求時會wait request pool, 每次request pool獲得一個請求時會notifyall 來解決忙等問題

度量分析

此次做業和上次做業基本沒有添加任何代碼， 所以複雜度和前一次做業基本相似。

第三次做業

做業任務描述

此次做業的內容以下

須要同時使用三部電梯， 而且每部電梯的使用樓層有限。

問題建模

此次問題依然沿用上次的架構， 稍微修改下乘客上下的條件便可。
A，B，C電梯分別負責不一樣的樓層， 設定1層爲換乘點， 在get request修改每一個電梯能夠得到請求的樓層就能夠完成此次的任務。

實現與類圖

在得到請求的時候， 加入了一些條件。
A電梯負責-1， -2， -3層， 和16-20層， 剩下的B和C電梯分別負責奇數和偶數層， 而且優先得到直達的顧客。
在乘客出電梯的時候， 須要判斷這一層電梯是否能夠停靠

此外， 在此次做業設計的時候， 還須要考慮電梯容量

我經過檢查當前電梯的大小和最大大小是否相等來判斷還可不能夠再上一我的。

線程分析

和前兩次做業相同， request pool爲互斥訪問， 三個電梯爲三個獨立的線程， 當沒有任務的時候，同時等待request pool得到任務， wait(), 每當request pool得到任務後， 使用notify來喚醒三個電梯。

度量分析

在此次做業中，control flow複雜度作的不是很好， 以後還能夠改進if語句， 不要有過多的分支。

Bug發現和解決

本身的代碼在強測和互測中都沒有被發現bug。

心得感覺

從此次做業中， 我感覺到了架構的重要性， 一個好的架構是能夠沿用到不少次做業裏的， 像這個單元的做業中， 我在第一次做業上花了一些時間思考架構， 第二次做業對代碼基本沒有修改， 第三次做業改了一些條件判斷的語句。 我體會到， 好的設計能夠減輕後面的工做量， 十分重要。